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CHAPTER  1 


INTRODUCTION 

j 

The  purpose  of  this  report  is  to  review  in  detail  the  type  checking  and  scope  rules 
for  the  specification  language  Z.  At  present  no  definitive  description  of  the  language 
exists,  although  it  is  sufficiently  well  defined  for  the  informal  use  which  is  currently 
made  of  it.  The  production  of  tools  to  process  the  language  requires  a  complete 
definition  during  the  production  of  which  a  number  of  decisions  are  made  concerning 
various  compromises  between  mathematical  elegance  and  efficiency  of  implementation. 

It  is  the  purpose  of  this  report  to  review  these  in  detail,  using  as  a  basis  the  syntax 
developed  by  King  et  al  (1987,  see  also  Sufrin  19861.  This  will  be  referred  to  as  the 
standard  syntax.  Rather  than  following  this  language  definition  mechanically  some 
changes  have  been  made,  with  the  following  motivations: 

This  report  is  concerned  particularly  with  tool  implementation,  so  a  version  of  the 
syntax  has  been  produced  enabling  syntax  and  type  checking  to  be  completed  in 
one  pass.  Changes  introduced  under  this  heading  do  not  affect  the  appearance  of 
the  language,  but  in  some  cases  a  syntactic  check  is  replaced  by  a  semantic  check. 

In  some  cases  variations  have  been  introduced  which  are  a  matter  of  personal 
preference.  The  production  of  variant  languages  in  this  way  is  actually  a  necessary 
step  towards  the  goal  of  the  production  of  a  robust  and  usable  language  standard. 

Most  of  the  other  cases  consist  not  so  much  in  change  from  what  has  been 
published  elsewhere  as  a  specification  of  the  detailed  meaning  of  the  language  for 
those  areas  which  have  not  been  described  in  detail,  in  particular  the  scope  rules 
and  the  properties  of  the  type  system. 

In  contrast  to  the  work  of  Spivey  119851,  which  is  concerned  with  the  formal 
semantics  of  the  language,  this  report  deals  with  aspects  of  the  implementation  of 
tools  to  process  the  language.  Because  of  this,  the  report  has  been  produced  in  the 
form  of  an  implementation  specification  for  a  type  checking  tool  for  a  language  which 
bears  a  more  than  passing  resemblance  to  Z  but  which  represents  the  preferences  of 
the  author  in  those  areas  where  the  Z  rules  are  debateable. 

Z  is  based  on  typed  set  theory  so  that  terms  in  Z  have  a  type  which  corresponds  to 
the  largest  set  of  which  the  term  could  be  a  member.  This  is  not  the  same  set  for 
every  term  (the  set  of  all  sets)  for  the  usual  reasons,  but  instead  types  are  associated 
with  given  sets,  schemas  and  sets  which  may  be  constructed  from  them  using  the 
powerset  and  tuple  constructors.  Thus  in  contrast  to  programming  languages,  functions 
do  not  have  a  special  type  constructor  but  have  the  same  type  as  relations  (powerset 
of  2-tuples)  which  allows  some  useful  expressions  to  be  constructed  without  the  need 
for  special  coercions. 

From  an  implementation  point  of  view,  the  most  interesting  aspect  of  type  checking  is 
in  the  limited  polymorphism  present  in  Z,  in  which  some  terms  may  have  a  generic 
type.  In  dealing  with  these  terms  the  ideas  of  Milner  (19781  have  been  followed  and 
developed  to  cover  the  various  constructions  available  in  Z.  The  greatest  difference 
in  this  area  between  Z  and  the  language  described  in  Milner's  paper,  or  the  related 
language  ML,  is  that  in  ML  alt  types  are  inferred  whereas  in  Z  the  types  (which  may 
be  polytypes)  are  given  in  a  signature.  This  leads  to  rules  for  the  handling  of 
polymorphic  signatures  and  also  for  the  use  of  those  signatures  at  positions  where  the 
corresponding  identifiers  are  being  defined.  This  will  be  discussed  in  more  detail  later. 

The  specification  itself  is  interesting  as  an  example  of  a  Z  specification  for  a 
reasonably  large  program;  this  report  is  a  complete  Z  specification  although  it  has 
not  been  passed  through  the  tool  it  specifies  as  the  implementation  remains  to  be 
done.  Consequently  it  no  doubt  contains  errors,  but  the  report  is  being  issued  now 
with  a  view  to  contributing  to  the  debate  on  the  precise  form  of  the  language.  The 
production  of  the  specification  has  been  rewarding  so  it  is  worth  recording  some  of 
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the  reasons  for  feeling  satisfied  with  the  process.  Apart  from  the  obvious  one  of 
having  a  precise  statement  of  the  problem,  these  are  as  follows: 

1.  An  extensive  specification  in  Z  may  be  produced  quickly.  This  has  a  number  of 
advantages.  It  is  for  example  possible  to  understand  the  problem  as  a  whole  and 
design  an  appropriate  module  structure  for  the  implementation  without  having 
to  find  this  out  the  hard  way  at  the  implementation  stage.  This  is  particularly 
the  case  in  the  question  of  the  design  of  data  structures.  A  standard  trauma  in 
program  development  is  to  discover  that  the  data  structure  one  has  been 
successfully  using  in  the  previous  twenty  modules  does  not  have  the  capability 
to  implement  some  feature  required  in  the  twenty  first,  leading  to  massive 
re-compilations.  By  having  a  complete  specification  for  the  whole  problem,  the 
capabilities  required  of  the  data  structures  can  be  made  visible  at  the  outset  of 
implementation. 

2.  The  formal  specification  is  particularly  useful  when  it  comes  to  expressing 
error  cases.  There  is  an  undoubted  psychological  reluctance  to  treating  these 
properly  and  the  fact  that  Z  provides  a  compact  notation  for  stating  the  error 
conditions  as  an  increment  to  the  standard  case  is  an  aid  to  overcoming  this 
barrier. 

3.  The  Z  notation  is  an  excellent  means  of  communication  between  specifiers 
and  implementers.  The  underlying  set  theory  is  easily  understood  and  the 
notation  is  compact  enough  not  to  obscure  the  overall  structure  with 
irrelevant  detail. 

4.  A  particularly  important  part  of  what  one  might  call  the  Z  specification 
technique  is  the  mathematical  toolkit,  the  standard  set  of  Z  mathematical 
functions  and  operators  which  enable  one  to  build  specifications  rapidly. 

Apart  from  the  characteristic  Z  schema  structures,  the  expressive  power  of 
the  notation  largely  rests  on  this  very  useful  library  of  functions. 

5.  Z  is  fun! 

The  structure  of  the  design  specification 

The  tool  envisaged  to  meet  this  specification  completes  syntax  analysis  and  type 
checking  in  one  pass,  so  the  specification  must  be  for  a  set  of  compiling  operations  on 
the  concrete  syntax,  rather  than  operations  on  the  abstract  syntax.  A  one-pass  type 
checker  will  require  declaration  before  use  rules  and  a  simple  scheme  of  lexical 
analysis.  No  apology  is  offered  for  this,  and  none  should  be  required  by  anyone  who 
has  suffered  from  trying  to  understand  a  specification  where  declaration  before  use 
does  not  apply. 

The  specification  for  each  compiling  operation  must  include  the  position  within  the 
syntax  at  which  the  operation  is  employed:  the  inputs  to  the  operation  in  the  form  of 
lexical  values  (the  identifiers  encountered,  the  values  of  numerical  constants  etc);  the 
state  variables  appropriate  to  the  operation,  most  notably  the  identifier  environment 
giving  the  relation  between  identifiers  and  their  types;  and  finally,  values  constructed 
during  the  course  of  compilation,  such  as  the  types  of  sub-expressions.  To  indicate 
the  relationship  between  these  various  items  and  the  specification  itself,  the  syntax 
notation  employed  in  the  syntax  transforming  tool  SID  will  be  used  (Foster  1968,  but 
see  also  Currie  19841.  This  may  be  briefly  described  by  means  of  un  example.  The 
following  fragment  of  input  to  SID  gives  a  syntax  for  numerical  expressions,  together 
with  compiling  functions  to  evaluate  the  resulting  integer. 

BASICS 

number  a  decimal  numbers  assembled  according  to  the  usual 

convention  a 

orb  a  (  a 

crb  a  )  a 
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plus 

*  +  * 

minus 

n  -  u 

mult iply 

*  *  u 

divide 

u  /  * 

RULES 

expression 

■ 

expression  addop  term  <opact ion-pint-pint-pint — int>» 
term; 

term 

= 

term  multop  primary  <opact ion-pint-pint-pint — int>* 
pr imary; 

pr i mary 

= 

<number-lv — int>  number* 

addop  primary  <monad i c-p i nt-p i nt — int>. 

orb  expression  crb; 

anyop 

= 

addop* 

multop; 

addop 

- 

<operatoi — 1 — int>  plus. 

<operator-2 — int>  minus; 

multop 

= 

<operatoi — 3 — int>  multiply. 

<operatoi — 4 — int>  divide; 

The  first  part  of  this  fragment,  under  the  heading  BASICS  lists  the  identifiers  to  be 
used  to  stand  for  the  terminal  symbols  of  the  syntax.  The  syntax  rules  appear  in  the 
second  part  of  the  fragment,  under  the  heading  RULES:  an  equals  sign  terminates  the 
name  of  the  rule,  a  comma  separates  alternatives  and  a  semi-colon  terminates  the 
definition  of  the  rule.  Each  alternative  within  the  definition  is  a  sequence  of  rules  or 
terminal  symbols  or  compiling  functions,  the  latter  being  indicated  by  angle  brackets. 
SID  is  able  to  transform  this  syntax  into  a  one-track  form  and  outputs  a  program 
which  will  perform  the  appropriate  syntax  analysis.  Where  compiling  functions  have 
been  included  the  analyser  will  call  them  at  the  appropriate  place  in  the  symbol 
stream:  for  example,  in  the  rule  for  expression  above,  the  function  opaction  will  be 
called  to  form  each  intermediate  result  in  an  expression  like  5+4+3. 

Within  the  angle  brackets,  the  name  of  each  compiling  function  is  followed  bv  strings 
involving  minus  signs.  Each  minus  sign  introduces  a  parameter  to  the  function,  a  final 
double  minus  indicates  the  type  of  the  result.  The  analyser  stacks  every  result  using  a 
different  stack  for  each  type:  thus  opaction  above  leaves  an  integer  on  the  stack  of 
integers.  Parameters  to  the  compiling  functions  can  only  come  from  the  stacks,  so 
following  each  minus  sign  is  the  type  of  stack  from  which  the  value  of  the  parameter 
is  to  be  obtained  and  which  will  be  supplied  by  the  analyser  when  the  function  is 
called:  the  type  will  be  preceded  by  a  p  or  a  q  according  to  whether  the  value  is  to 
be  supplied  by  a  "pop'  or  a  "top”  operation.  With  this  notation,  it  is  useful  to  think 
of  the  syntax  rules  as  delivering  values  onto  the  appropriate  stack.  Thus  opaction  in 
the  rule  for  expression  above  takes  the  integer  delivered  by  the  term,  the  integer 
corresponding  to  the  operation  (♦  or  -)  and  the  integer  corresponding  to  the  previous 
subexpression  and  combines  them  to  produce  a  new  integer  which  will  be  the  result  of 
the  expression,  which  may  be  thought  of  as  the  result  of  the  whole  phrase. 

There  are  two  other  forms  of  parameter  which  are  allowed  to  compiling  functions. 
These  are  -lv,  in  which  case  the  lexical  value  of  the  symbol  to  the  right  will  be 
supplied,  and  -n,  where  n  is  a  small  integer  representing  the  value  to  be  supplied 
This  latter  case  is  used  when  a  number  of  compiling  functions  are  simple  variations  on 
a  common  theme:  in  this  example  the  operator  function  presumably  simply  stacks  its 
parameter  to  indicate  to  opaction  which  action  is  actually  required 

After  this  lengthy  excursion  into  the  details  of  SID,  it  is  now  possible  to  give 
the  conventions  for  specifying  the  compiling  functions.  These  are: 
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1.  Each  compiling  function  is  specified  by  a  Z  schema  definition  of  the  same  name. 

2.  Each  specification  is  preceded  by  the  fragment  of  SID  syntax  which  uses  it. 

3.  Each  parameter  to  a  compiling  function  is  represented  as  an  input  to  the 
operation  (using  ?). 

4.  The  result  of  each  function  is  represented  as  an  output  (using  1). 

In  the  specification  which  follows,  each  chapter  is  a  Z  document.  As  the 
implementation  is  based  on  the  Flex  computing  concepts  (Foster  et  al  19821,  which  is 
an  object  oriented  machine,  documents  are  represented  by  module  values,  rather  than 
the  name  of  the  document  as  in  the  standard  syntax.  These  modules  appear  in  the  text 
as  icons:  |Z_spec  iflodule^  one  for  each  document  imported.  The  compiling  functions 
for  creating  and  using  these  module  values  are  not  defined  in  this  specification  as 
they  are  peculiar  to  the  Flex  architecture  adopted.  The  Z  syntax  has  also  been 
extended  to  include  an  export  statement  in  the  form: 

document  keeps  id,  id,... 

which  indicates  the  identifiers  made  available  when  the  document  is  incorporated. 

Most  of  the  strategy  of  type  checking  is  discussed  in  the  datatypes  chapter  which 
contains  correspondingly  more  descriptive  text  compared  with  the  other  chapters 
which  are  concerned  with  the  details  of  type  checking.  The  appendix  contains  the 
complete  syntax. 
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CHAPTER  2 


BASIC  REPRESENTATIONS 


Identifiers 


The  lexical  analyser  has  the  task  of  sorting  out  base  names  and  decorations  and 
produces  a  member  of  the  set  Id.  defined  by  a  schema  below,  for  every  identifier 
encountered.  The  base  name  is  represented  by  a  line  of  characters,  which  may  be 
emboldened,  underlined  or  not: 

weight  ::=  light  I  bold  I  underlined  i  underbold 
decline  a  Cl  :  seq  Char ;  w  :  weight! 

Name  ::=  noname  I  1 i needed ine> 

In  fact,  as  far  as  the  specification  is  concerned,  Name  could  be  a  given  type,  but  this 
does  at  least  indicate  that  lexical  items  are  emboldened  or  not  as  a  whole.  Decoration 
is  either  a  subscripted  string  (a  version)  or  an  attribute  or  both.  The  version  is 
represented  by  a  sequence  of  Name  to  allow  for  an  arbitrarily  complex  label.  An 
attribute  is  one  of  exclamation  mark,  query  or  a  series  of  dashes:  the  view  has  been 
taken  that  these  are  mutually  exclusive,  so  identifiers  of  the  form  x !  !  or  x7 !  are 
illegal.  Consequently  it  is  possible  to  define  a  datatype  Att  to  indicate  the  possible 
attributes  of  an  identifier. 

Att  ::=  noatt  I  bang  I  query  I  dashes«N» 

The  integer  parameter  of  the  dashes  constructor  is  the  number  of  dashes. 

Each  identifier  has  a  syntactic  status  which  is  used  by  the  lexical  analyser  to  decide 
what  sort  of  terminal  symbol  the  identifier  should  be:  the  syntactic  status  is  by 
default  that  of  an  ordinary  identifier,  but  may  be  changed  during  the  course  of 
compiling  a  definition  to  be  that  of  an  infixed  or  other  operator,  or  a  generic  set. 

Synstatus  ::=  ident  I  op  I  encop«Name>  I  d i st i nop«Name» 

I  d i stpreop«Name>  i  preop  I  postop  I  rel 
I  preset «Name»  I  post set «Name»  I  insetCseq  Name» 

The  Name  parameter  of  the  constructors  for  the  operators  is  the  closing  eop.  For  the 
sets,  the  name  parameter  indicates  the  generic  parameter  identifier  or  identifiers,  used 
when  the  set  is  being  instantiated.  Identifiers  are  represented  by  the  schema  below, 
which  indicates  that  only  one  version  is  allowed  and  version  and  attribute  may  be 
supplied  in  either  order  and  represent  the  same  identifier.  That  is,  x !  ^  is  the  same 

identifier  as  Xj  1 

rId —  - - 

name,  version  :  Name 

att  :  Att;  synstat  :  Synstatus 


Lexical  values 


The  decoration  of  identifiers  is  handled  by  the  lexical  analyser,  rather  than 
syntactically,  so  the  output  from  lexical  analysis  is  an  identifier,  even  when  the 
decoration  appears  on  its  own  (as  in  schema  terms).  It  is  convenient  for  the  lexical 
analyser  to  buffer  these  identifiers  and  decorations  in  a  global  queue  which  forms  the 
part  of  the  lexical  state  visible  to  the  compiling  functions: 
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LexStateO 

LexState 


LexState _ , 

idl ist  :  seq  Id 

■ 


idl ist  =  <  > 

1 


As  •  result,  lexical  values  delivered  by  the  SID  generated  syntax  analyser  need  only 
distinguish  integers,  characters  and  strings,  to  handle  explicit  denotations  for  these 
values. 


Lexical  ::=  num«2»  I  char«Char3>  i  string«seq  Char» 


Representation  of  types 

A  representation  of  types  is  proposed  in  Spivey  (19851,  but  it  has  been  found 
necessary  to  extend  this,  for  three  reasons: 

1.  It  is  necessary  to  cater  for  the  distinction  between  generic  and  given  types. 

2.  For  the  implementation  of  type  checking  in  expressions  it  is  necessary  to  infer 
the  types  of  instantiation  for  generic  identifiers.  This  has  been  done  by  the 
introduction  of  types  constructed  from  type  variables,  which  may  be  substituted 
by  an  inferred  type  value. 

3.  Also  for  the  purposes  of  the  implementation,  the  datatype  has  been 
extended  to  include  predicates  and  an  undefined  type,  which  is  used  for 
undeclared  identifiers. 

Type  variables  are  represented  by  type  names  TName,  which  refer  to  values  in  a  type 
environment  (which  will  have  type  TName  ■*»  Type):  substitutions  are  brought  about  by 
altering  the  type  environment.  The  type  names  are  introduced  as  a  given  set: 

[ TName 1 


Type  ::=  given«Id»  I  powerset  «Type»  I  tuple«seq  Type» 

I  5chema_type«Id  -»Type» 

I  genericClN  *  Id  )»  I  var i able«TName» 

I  predicate  I  type_undef i ned 

The  elements  of  this  disjoint  union  will  be  discussed  in  turn. 

1.  Given  sets 

A  given  set  must  be  treated  as  atomic  throughout  the  document,  and  may  only  be 
changed  as  a  result  of  the  instantiation  of  a  previously  compiled  document. 
Consequently  it  must  be  distinguished  from  a  generic  type,  which  may  be  instantiated 
at  different  types  within  the  document  which  defines  it.  The  Id  is  the  identifier  of 
the  given  set,  unique  within  the  document.  This  type  is  also  used  for  data  types. 

The  types  2  and  Char  are  datatypes  and  built-in  to  the  extent  that  numbers  and 
strings  are  recognised  as  having  the  appropriate  type.  For  the  purposes  of  this 
specification,  it  will  simply  be  asserted  that  these  two  types  exist: 

Ztype,  Char type  :  Type 

It  may  be  observed  at  this  point  that  datatypes  are  one  of  the  few  constructions 
in  Z  which  are  not  allowed  to  be  generic.  One  can  imagine  a  construction  like 

IT]  Tree  leafcT»  |  nodeCT  Tree  *  T  Tree* 
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for  polymorphic  tree  structures  for  example,  which  would  be  useful.  To  cope  with 
this,  the  type  representation  would  have  to  be  extended  with  a  generic  data  type 
constructor  dependent  on  a  sequence  of  types  (the  generic  parameters)  and  an 
identifier,  the  data  type  name.  This  identifier  would  have  a  value  within  the 
environment  corresponding  to  a  (preferably  postfix)  generic  set  instantiating  a  tuple  as 
a  parameter  and  delivering  the  appropriate  type.  This  extension  has  not  been  made, 
mainly  because  the  semantics  of  such  data  types  have  not  been  specified,  but  there 
seems  to  be  no  reason  to  suppose  that  this  extension  would  introduce  inconsistencies. 
This,  of  course,  is  not  an  argument  for  including  it. 

2.  Powersets,  tuples  and  schema  types 

These  are  standard  type  constructors,  as  given  by  Spivey. 

3.  Generic  and  variable 

Generic  types  may  either  be  instantiated  by  name  or  anonymously;  in  the  latter  case 
the  type  of  their  instantiation  is  inferred  from  their  use,  using  the  algorithm  specified 
by  Milner.  To  correspond  to  these  two  usages  are  two  different  representations, 
generic  and  variable.  A  generic  type  is  constructed  from  an  identifier  corresponding 
to  the  generic  parameter  and  an  integer:  the  integer  is  for  instantiation  with  a  list  of 
terms,  rather  than  by  name.  A  generic  type  is  treated  as  atomic  within  the  generic 
definition  which  uses  it  and  elsewhere  it  is  used  to  create  the  appropriate  type  on 
named  instantiation.  When,  on  the  other  hand,  type  instantiation  is  done  by  inference, 
a  variable  type  is  created  from  the  generic  type  to  allow  substitution  of  the  inferred 
type  of  instantiation  for  the  generic  type.  The  variable  type  is  represented  by  a  type 
name,  which  is  used  to  refer  to  a  type  environment  where  the  substitutions  are 
actually  made.  By  this  means,  one  substitution  accounts  for  all  instances  of  the  generic 
type  within  the  type  representation.  (An  example  of  a  multiple  instance  is  the 
identity  relation  which  has  type  P(T  *  T  ),  where  the  T  are  generic.  An  instance  of 
the  identity  must  be  inferred  to  have  type  P12  *  2 )  as  soon  as  either  the  domain  or 
range  are  found  to  be  integers.)  A  new  type  variable  is  created  for  each  generic  type 
on  every  occasion  when  the  identifier  bearing  that  generic  type  is  instantiated.  This 
is  done  by  using  a  new  name,  drawn  from  the  given  set  of  type  names,  Tname,  and 
different  from  any  other  name  currently  in  use,  for  each  of  the  differing  identifiers  in 
the  generic  type.  Type  checking  of  an  expression  involving  such  type  variables  is 
done  using  type  unification  which  will  result  in  some  substitution  of  types  for  the  set 
of  names.  Variable  types  only  have  a  meaning  within  an  environment  giving  the 
substition  of  types  for  names,  which,  is  maintained  as  part  of  the  global  state. 

4.  Predicate 

This  is  a  special  built-in  type,  not  accessible  to  the  user,  which  is  used  to  unify  the 
type  checking  of  terms  and  predicates.  For  various  reasons,  both  terms  and  predicates 
are  members  of  the  same  syntactic  class,  so  it  is  helpful  to  have  a  special  type  to 
distinguish  them  semantically. 

5.  Undefined 

This  is  a  type  for  undeclared  identifiers,  used  to  suppress  type  checking  and 
consequential  spurious  error  messages. 

A  subset  of  these  types  are  the  atomic  types,  defined  by: 

Wype  a  rng  generic  U  rng  given  U  {predicate,  type_undef i ned> 


Z_datatypes  keeps 

Name,  noname/  line,  decline, 
fltt.  noatt.  bang,  query,  dashes, 

Synstatus,  ident.  op,  encop,  djstinop,  distpreop,  preop, 
postop,  rel ,  preset,  postset,  inset. 

Id.  LexState,  LexStateO.  LexUal.  num,  char,  string, 

TName.  Type,  given,  powerset,  tuple,  schema_type,  generic, 
variable,  predicate,  t ypejjndef in ed.  Ztype,  Chartype,  HType 
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CHAPTER  3 


THE  IDENTIFIER  ENVIRONMENT 


|Z_datatypes  i Module 

The  identifier  environment  gives  the  types  associated  with  each  identifier.  It  is  made 
up  of  scopes  such  as  those  associated  with  the  global  document,  or  the  local 
declarations  of  a  schema,  and  scopes  from  imported  documents.  A  scope  defines  a 
look-up  function,  (Id-*»Type),  for  the  identifiers  which  have  been  declared  at  the 
same  static  level:  the  rule  of  declaration  before  use  is  followed,  so  the  scope  can  be 
changed  incrementally  as  new  identifiers  are  declared.  A  new  scope  is  created  at  the 
beginning  of  a  document,  for  the  local  declarations  in  a  schema,  a  theorem,  a 
comprehension  and  in  many  other  places.  Associated  with  each  scope  is  a  sequence  of 
types  used  to  calculate  the  characteristic  tuple  corresponding  to  a  scope. 
Cnaracteristic  tuples  are  used  to  calculate  the  types  of  X  expressions  and  other 
comprehensions.  For  these  constructions  the  type  is  regarded  as  a  tuple  formed  from 
the  declaration  list,  in  which  each  identifier  and  inclusion  contributes  a  member  in 
the  order  in  which  they  were  introduced.  For  the  particular  case  of  X  expressions, 
the  characteristic  tuple  is  a  somewhat  dubious  concept  if  two  inclusions  have  a  part 
of  the  signature  in  common.  For  example,  within  the  context  of  the  schema  definitions 
Pa  t  i  ,  j  :  N 1  and  B4  t  j ,  k  :  N 1 ,  X  A ;  B  •  j  has  the  type  (A  »  B  )  -» N, 
which  leads  to  difficulties  when  the  function  is  applied  to  a  tuple  in  which  the  j 
components  differ.  The  view  has  been  taken  that  inclusions  with  overlapping 
signatures  in  this  way  are  an  error  when  used  to  make  up  a  X  expression,  so  some 
indication  needs  to  be  kept  within  the  current  scope  that  it  is  destined  to  form  the 
parameter  of  a  X  expression.  This  is  done  using  the  datatype: 

scope_type  ::=  lambda  I  mu 

Also  associated  with  each  scope  is  an  integer  used  to  keep  track  of  the  order  of 
generic  identifiers.  This  is  gathered  together  with  the  other  information  to  form  a 
Block: 

Block  _ , 

ids  :  Id-»Type;  ctuple  :  seq  Type 
st  :  scope_type;  lastjeneric  :  N 

An  imported  document  also  introduces  a  set  of  identifiers,  but  these  are  not  allowed  to 
override  previous  declarations.  This  is  for  reasons  of  good  practice  rather  than 
logical  consistency,  because  it  is  not  a  good  idea  to  have  the  same  identifier  present 
with  two  different  meanings  within  the  same  document.  However,  an  identifier  in  a 
document  overrides  the  same  identifier  in  a  previously  introduced  document  for 
reasons  of  efficiency:  it  is  hard  to  keep  track  of  all  uses,  within  the  current 
document,  of  identifiers  from  external  documents  and  it  is  unreasonable  to  expect 
external  documents  to  have  no  identifiers  in  common.  This  behaviour  may  be  modelled 
using  the  following  definitions.  First  of  all,  the  identifier  environment  itself: 

_  Env  | 

blocks  :  seqt  Block 
docs  :  seqj(Id-**Type  1 
docnames  :  Id -•*  Id  Type 


rng  docnames  =  rng  docs 


A  particular  imported  document  may  be  searched  using  a  document  name  and  the 
function  docnames:  alternatively  all  documents  may  be  searched  using  docs.  The 
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constraint  ensures  that  either  method  uses  consistent  look-up  functions.  There  is 
always  one  block  present  in  the  sequence  of  blocks,  namely  the  global  scope  of  the 
current  document,  and  there  is  always  one  document,  the  Z  library. 

An  override  function  may  be  defined  for  sequences  of  look-up  functions  as  follows: 


/•_  s  seqt  (Id-»Type  ) -» ( Id -»Type  ) 


W  1  t  seqj(Id-»Type ) 

.  «tl  =  1  -*  /•  1  =  hd  1 

Ml  >  1  -*  /•  1  =  (/•  Ctl  1))  •  (hd  1) 


where  e  is  the  relational  overrride  operator.  This  function  delivers  a  look-up 
function  in  which  the  identifiers  defined  in  scopes  near  the  beginning  of  the  sequence 
override  those  at  the  end.  the  implication  being  that  scopes  are  stacked  rather  than 
queued.  The  function  find  env  delivers  the  type  of  an  identifier  stored  in  a  given 
environment: 


find  t  Env  -» Id  ■♦•Type 


y  env  •.  Env 

•  find  env  =  doc  ids  •  block  ids 
where 

doc  ids  £  /#  env. docs 

ids  £  X  Block  •  ids 

block  ids  £  /•  (env. blocks  i  ids) 


and  f  i  nd_doc  finds  from  a  given  document: 

find_doc  £  X  env  :  Env;  ident  :  Id 

I  ident  e  dom  env.docnames 
•  env.docnames  ident 

Declarations  and  inclusions  change  the  look-up  function  and  characteristic  tuple  in 
the  current  scope  and  nothing  else,  so  it  is  convenient  to  define  the  schema: 

pAEnv  - - - 

I  Env;  Env' 

I  fiBlock 


SBlock  =  hd  blocks  a  SBlock’  =  hd  blocks' 

tl  blocks  =  tl  blocks’ 

docs'  -  docs  a  docnames'  =  docnames 

st '  =  st  a  lastjgener ic’  =  last_generic 


The  initial  environment  consists  of  one  empty  block  and  a  set  of  documents  making  up 
the  Z  library: 
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Z_lib  :  seq,  ( Id  +*Type  ) 

Z_lib_pam*s  :  Id  ■»  Id  ■»  Type 
empty_b!ock  a  p  Block 

I  ids  =  O  a  ctuple  *  ( >  a  st  =  mu 
a  last_aeneric  =  0 
•  eBlack 


_EnvO 
[  Env 


blocks  =  <emptyJolock > 
docs  =  Z_1  ib 
docnames  =  Z_lib_names 


Entering  and  leaving  a  scope 

On  entering  a  scope  a  new  empty  block  is  added  to  the  environment,  on  leaving  it, 
the  current  block  is  removed: 


new_£cope 
I  Env;  Env' 


blocks’  =  emptyjalock  cons  blocks 
docs’  =  docs 
docnames'  =  docnames 


and  entering  a  X  expression  is  a  simple  variation: 


new_lambda_scope 
I  Env;  Env' 


end_scope  _ 

Env;  Env’ 

blocks’  =  tl  blocks 
docs’  =  docs 
docnames’  =  docnames 


blocks’  =  lambda_block  cons  blocks 
where 

lambdajblock  &  p  Block 

|  ids  =  O  a  ctuple  =  ( > 
a  st  =  lambda  a  last_aeneric  =  0 
•  eBlock 

docs'  =  docs 
docnames’  «  docnames 


Adding  new  identifiers  to  an  environment 

In  standard  Z  it  is  possible  to  redeclare  an  identifier,  providing  the  types  are 
compatible.  This  seems  to  be  a  somewhat  dubious  facility  as  it  may  lead  to  some  user 
mistakes  going  undetected,  besides  allowing  for  the  implicit  introduction  of  additional 
constraints  which  ought  really  to  appear  explicitly  in  a  predicate.  In  addition  the 
effect  on  the  characteristic  tuple  of  the  environment  is  questionable.  For  this  reason, 
a  new  declaration  is  not  allowed  to  over-ride  an  existing  declaration  within  the 
current  block.  In  the  general  case,  declarations  involve  a  sequence  of  identifiers  each 
to  be  given  the  same  type  so  the  declaration  operation  is: 


It 


—  Declare  .  . 

AEnv 

new_ids  :  seq  Id;  ty  :  Type 
rep!  :  seq  Char 


ids’  =  ids  U  good_ids 

duple*  =  ctuple~(new_i ds  i  (X  Id  •  ty)) 
bsd_ids  x  O  rep!  =  "Identifier  declared  twice" 
where 

bad_ids  a  rng  new_ids  n  dom  ids 
good_ids  a  -C  ident  :  rng  new_ids 
I  ident  S  dom  ids 
•  ident  ty> 


Schama  merging 

In  this  case  added  identifiers  are  allowed  to  be  present  in  the  current  scope,  provided 
they  have  the  same  type.  The  following  function  delivers  the  inconsistent  identifiers: 

(_  inconsistent  _)  a  X  x.  y  t  Id**Type 
•  -fident  :  Id 

I  ident  e  dom  x  D  dom  y 
a  x  ident  x  y  ident 

> 

Note  that  schema  merging  is  done  after  type  normalisation  (see  chapter  5)  which 
removes  all  variables  from  a  type,  so  a  simple  test  for  equality  of  types  is  all  that  is 
required,  rather  than  type  unification.  This  corresponds  with  the  rule  that  types  for 
identifiers  stored  within  the  environment  should  be  fully  defined.  The  new  scope  is 
formed  by  merging  the  consistent  part  of  the  look-up  function: 

_  Merge  _ _ i 

AEnv 

merge_ids  ;  Id-«Type 
rep!  :  seq  Char 


ids'  =  good_ids  U  ids 

bad_ids  x  O  — *  rep!  =  "Identifiers  inconsistent" 
where 

bad_ids  a  merge_ids  inconsistent  ids 
good_ids  a  bad_ids  4  merge_ids 


The  basic  operation  for  a  schema  inclusion  is  given  by  adding  a  check  for  overlapping 
schema  signatures  and  a  calculation  of  the  characteristic  tuple  of  the  scope.  This  is 
always  done,  even  in  the  global  scope,  for  reasons  of  simplicity. 


12 


Z_scopes  keeps  lambda#  mu#  Block#  Env#  find#  find_doc#  new_scope# 
end_scope>  new_lambda_scope #  Declare#  inconsistent. 
6Env#  flerae#  Include#  Schema#  Schema_ok 
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CHAPTER  4 


UNIFICATION  OF  Z  TYPES 

|Z_datatypes  ;Hodule| 

Generic  types 


Most  useful  general  purpose  mathematical  functions  are  generic,  that  is,  they  are 
defined  for  a  range  of  types.  A  typical  example  is  the  function  dom  which  may  be 
applied  to  any  relation,  no  matter  what  its  type,  to  give  the  domain  of  application. 

Z  supports  this  facility  by  allowing  most  constructions  within  the  language  to  be 
generic,  the  type  parameters  being  supplied  with  the  definition.  To  check  types 
during  the  course  of  an  expression  such  as  dom  R,  where  R  is  a  relation,  it  is 
necessary  to  know  the  particular  type  which  this  instance  of  dom  should  have.  This 
can  be  provided  by  the  user  using  the  named  instantiation  facilities,  but  this  would  be 
impossibly  tedious  for  functions  like  dom  which  are  used  so  extensively.  In  fact  it  is 
possible  to  infer  the  required  type  for  a  generic  term  from  its  use.  using  an  algorithm 
due  to  Milner  119781,  and  this  is  the  approach  adopted  here. 

The  algorithm  has  two  parts:  in  the  first  part,  generic  types  are  instantiated  as  a 
type  expression  in  which  the  generic  components  have  been  replaced  with  variables. 
This  process  is  specified  in  the  module  concerned  with  anonymous  instantiation, 
(chapter  7).  The  second  part  of  the  type  inference  process  occurs  during  the  various 
forms  of  type  checking  which  appear  within  the  compiling  functions  throughout  this 
specification.  These  all  eventually  involve  some  test  for  type  equality:  this  may  be  a 
simple  test  if  the  types  are  not  generic,  but  if  they  are,  the  type  inference  algorithm 
enables  them  to  be  judged  equal  if  a  substitution  of  types  for  the  variables  within  the 
generic  types  could  be  found  which  would  make  them  equal,  for  this  can  be  the  type 
of  instantiation  of  some  generic  term.  The  process  of  substituting  expressions  for 
variables  in  order  to  make  two  terms  equal  is  called  unification  and  a  theorem  due  to 
Robinson  119651  asserts  that  an  algorithm  exists  to  find  the  minimum  substition  for  any 
two  terms  which  will  in  fact  unify,  and  the  specification  of  this  algorithm, 
particularised  for  the  Z  type  expressions,  is  the  subject  of  this  module. 

Type  unification 

In  this  implementation,  the  variables  in  a  type  expression  are  represented  by  type 
names  drawn  from  the  set  TName  and  a  type  environment  Tenv,  a  function  from  names 
to  types. 

Tenv  &  TName  •«  Type 

The  substitution  of  a  type  for  a  variable  is  brought  about  by  changing  the  type 
environment,  which  as  a  result  contains  the  set  of  substitutions  appropriate  for  the 
types  under  consideration.  The  unification  algorithm  is  represented  by  a  function 
unify,  which  takes  the  current  type  environment  and  two  types  and  delivers,  if 
possible,  a  new  type  environment  in  which  the  two  types  are  equal;  otherwise  a  reply 
is  delivered  with  the  new  environment  containing  the  substitutions  made  before  the 
incompatibility  was  discovered.  The  type  of  the  result  of  unify  is  given  by  the 
schema  Uresult: 

Uresult _ , 

1  tenv’  t  Tenv 

rep!  :  seq  Char 


unify  :  (Tenv  *  Type  *  Type  )-»Uresult 
The  unification  function  will  be  specified  incrementally  in  terms  of  the  various  cases 
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for  the  structure  of  the  type  input  values,  ending  up  with  a  global  constraint  which 
defines  the  function.  For  this  it  is  useful  to  gather  up  the  parameters  and  result  of 
unify  into  the  schema: 
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Un i par  s  _ 

tenv:  Tenv;  tyl»  ty2  :  Type 
Uresult 

■ 

First  of  all,  the  unification  of  types  which  are  variable  but  for  which  a  previous 
substitution  has  been  made  is  specified  as  follows: 

Puns _ t 

Uni  pars 


tyl  c  rn9  variable  a  nl  c  dom  tenv  — » 
SUresult  =  unifyttenv,  tenv  nl.  tyZ  ) 

where 

nl  &  variable'1  tyl 


A 

ty2  e  rng  variable  a  n2  e  dom  tenv  — * 
flUresult  =  unifyitenv.  tyl,  tenv  n2 ) 

where 

nZ  a  variable'1  ty2 


Immediately  after  instantiation,  a  type  variable  has  no  type  substituted  for  it, 
represented  by  its  absence  from  the  domain  of  the  type  environment.  If  a  substitution 
does  exist,  the  name  will  be  present  in  the  type  environment  and  the  substituted  types 
are  unified.  Note  that  a  proof  obligation  has  been  incurred  for  the  case  where  both 
types  are  variables,  in  which  case  it  is  necessary  to  show  that  the  two  constraints 
may  be  satisfied  simultaneously:  this  will  only  be  the  case  if  substitutions  for  both 
type  variables  are  taken  into  account. 

A  variable  for  which  no  substitution  exists  may  be  substituted  by  any  type  which 
does  not  depend  on  this  variable.  This  can  be  checked  using  the  following 
function  which  gives  the  unassigned  names  in  a  type. 


IS 


names  :  (Tenv  *  Type)-»P  TName 


tl  tenv  :  Tenv;  ty  :  Type;  result  :  P  TName 
I  result  =  names(tenv>  ty ) 

•  ty  e  AType  a  result  *  O 
v 

ty  e  rng  var iable 

n  t  dom  tenv  a  result  =  {n> 
v 

n  €  dom  tenv  a  result  =  names_in_type(tenv  n) 
where 

n  s  variable'1  ty 
v 

ty  e  rng  powerset  A  result  s  names_in_type(powerset'1  ty) 
v 

ty  e  rng  tuple  a  result  =  U  names_in_typeCrng(tuple'1  ty)) 
v 

ty  e  rng  schema_type  a 

result  =  U  names_in_typeCrng(schema_type'1  ty)) 

where 

names_in_type  a  X  ty  :  Type  •  names! tenv,  ty) 


Either  type  may  be  a  variable,  giving  rise  to  two  schemas  for  substitution.  If  both 
types  are  variables,  either  may  be  substituted  for  the  other.  If  one  of  the 
types  is  dependent  on  the  other,  the  only  allowable  case  is  for  both  types  to  be 
equal,  in  which  case  no  substitution  is  required. 

_ RHsubs  —  -  , 

I  Uni  pars 


tyZ  e  rng  variable  a  nZ  *  dom  tenv 
nZ  e  namesttenv,  tyl )  a 

tenv’  =  tenv  U  -CnZ  *♦  tyl>  a  rep!  *  "OK" 
v 

nZ  e  namesttenv,  tyl)  a  tyl  *  tyZ  a 
tenv’  *  tenv  a  rep!  =  "OK" 

V 

nZ  e  namesttenv,  tyl)  a  tyl  *  tyZ  a 

tenv’  =  tenv  a  rep!  =  "Illegal  type" 

where 

nZ  a  variable'1  tyZ 


LHsubs  . 
I  Uni  pars 


tyl  c  rng  variable  a  nl  t  dom  tenv 

nl  e  namesttenv,  tyZ )  a 

tenv'  *  tenv  U  <nl  ~  tyZ>  a  rep!  =  "OK" 
v 

nl  «  namesttenv,  tyZ )  a  tyl  =  tyZ  a 
tenv*  *  tenv  a  rep!  =  "OK" 
v 

nl  e  namesttenv,  tyZ  )  a  tyl  *  tyZ  a 

tenv'  *  tenv  a  rep!  *  "Illegal  type" 

where 

nl  a  variable'1  tyl 


j 
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The  remaining  schemas  cover  the  non-variable  cases,  given  by  this  schema: 

Novars  _ _  -  - 

I  Uni  pars 


tyl  t  rng  variable  a  ty 2  t  rns  variable 


The  undefined  type  is  used  for  undeclared  variables  and  suppresses  some  consequential 
error  messages.  It  is  defined  to  unify  with  any  type. 

_ Undef  i  ned  . _  .  .  -  . . _  , 

)  Uni  pars 


tyl  =  type_undef ined  v  t y2  =  type_undef i ned 
tenv’  =  tenv  a  rep!  =  "OK’ 


All  other  atomic  types  unify  if  they  are  the  same: 

Un  i  atoms  .  . .  - 

I  Un  i  pars 


tyl  €  ftType  \  <type_undef ined> 
tyZ  e  AType  \  <type_undef ined> 
tenv'  =  tenv  a  tyl  =  ty2  a  rep!  *  "OK” 


Powersets  unify  if  they  are  constructed  from  types  which  unify: 


Un i powers 
Uni  pars 


tyl  e  rng  powerset  a  tyZ  e  rng  powerset 
eUresult  =  unifyftenv,  tya,  tyb) 
where 

tya  a  powerset"1  tyl 
tyb  a  powerset"1  tyZ 


Tuples  require  the  unification  of  sequences,  which  is  defined  to  occur  between  pairs 
of  sequences  of  the  same  length  and  to  terminate  at  the  end  of  the  sequence  or  when 
corresponding  elements  of  the  sequence  fail  to  unify.  Each  unification  takes  place 
within  the  type  environment  resulting  from  previous  unifications  in  the  sequence. 
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unifyseq  :  CTcnv  *  seq  Type  «  seq  Type )  —Uresult 


y  tenv  :  Tenv;  tysl,  tys2  ••  seq  Type  I  etysl  =  *tys2  *  1 

•  un ifyseq(tenv.  tysl,  tys2  )  =  unify(tenv,  hd  tysl,  hd  tys2 ) 
y  tenv  :  Tenv?  tysl.  tys2  :  seq  Type  I  *tysl  =  *tys2  >  1 

•  url.rep!  “  "OK*  a 

unifyseq(tenv,  tysl/  tys2  )  = 

unifyseq(url.tenv’ ,  tl  tysl.  tl  tys2 ) 

url.rep!  *  "OK"  a 

unifyseqttenv.  tysl.  tys2 )  =  url 
where 

url  a  unifyftenv.  hd  tysl.  hd  tys2 ) 


Un  i  tuples 
I  Lin  i  par  s 


tyl  e  rng  tuple  a  ty2  e  rng  tuple  a  »tya  =  «tyb 

SUresult,  =  un  ifyseqftenv.  tya.  tyb  ) 
where 

tya  a  tuple"1  tyl 
tyb  a  tuple*1  ty2 


The  unification  of  schemas  differs  from  the  scheme  proposed  by  Spivey  11985).  which 
it  is  felt  may  be  confusing  to  users.  In  this,  the  standard  scheme,  schemas  unify  if 
their  identifiers  art-  identical  and  corresponding  types  unify.  This  leads  to  problems 
because  one  requires  expressions  like  85TATE  =  85TATE’  to  type  check  correctly,  so 
an  additional  rule  ,s  made  that  decoration  does  not  change  the  type  of  a  schema. 
Unfortunately,  if  tne  decoration  is  bound  in  with  the  schema,  either  by  providing  it 
explicitly  in  the  signature  or  within  a  schema  definition  such  as  T  a  S'  the  types 
become  different  and  may  not  check  in  situations  in  which  the  defining  terms  would. 

In  this  particular  example  T  and  S  would  not  have  the  same  type  and  neither  would  T 
and  S’,  which  is  couiter- intuitive.  In  addition  it  is  not  clear  what  type  should  be 
ascribed  to  s  in  the  declaration  s  :  S’  or  f  in  f  a  X  5;  S'  •  term. 

The  scheme  adopted  here  uses  the  alternative  discussed  by  Spivey,  in  which  schema 
types  unify  if  the  identifiers  agree  modulo  any  decoration  common  to  all  of  the 
identifiers  in  one  schema,  and  the  corresponding  types  unify.  This  means  that  although 
the  underlying  type  representations  differ,  the  predicate  85TATE  =  8STATE’  still 
type  checks  correctly  and  the  term  (eSTATE,  BSTATE’  )  will  also  type  check  as  a 
member  of  a  homogeneous  relation  on  STATE.  In  addition,  any  types  which  would 
agree  (in  the  sense  of  forming  a  correctly  type  checked  expression)  under  the 
standard  scheme,  will  also  agree  under  this  one,  but  some  types  will  agree  under  this 
scheme  which  will  not  agree  under  standard  one.  However,  checks  on  schema  merging, 
and  the  schema  operations  generally,  are  applied  to  the  type  representation,  so  some 
operations  are  not  allowed  under  this  scheme  which  would  be  under  the  standard.  A 
typical  one  would  be  s  :  STATE!  s’  :  STATE’  which  does  not  form  a  suitable 
identifier  pair  for  schema  composition  (whereas  s,  s'  :  STATE  would).  It  is,  in  fact 
debateable  which  of  the  two  approaches  will  be  less  confusing  to  the  users,  but  it  is 
in  any  case  a  fine  distinction  and  hardly  observable  to  tho  user,  so  there  does  not 
seem  to  be  a  problem  with  adopting  this  approach.  The  advantage  of  the  approach  is 
that  the  type  now  contains  all  the  information  necessary  for  checking  schema 
operations  and  inclusions,  which  considerably  simplifies  the  implementation. 

The  implementation  must  check  the  types  within  the  schemas  one  at  a  time,  so  the 
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specification  defines  an  ordering  within  the  identifiers  of  the  schema  and  uses  this  to 
construct  the  sequence  of  types  to  be  checked. 

I  order  :  P  Id-*seq  Id 


b  ids  :  P  Id;  list  :  seq  Id 
I  list  =  order  ids 

•  rng  list  =  ids  a  dom  list  =  1  ..  aids 

This  is  not  a  complete  specification  as  the  identifiers  are  required  to  be  totally 
ordered  such  that  the  addition  of  a  decoration  does  not  alter  the  order.  The 
specification  of  this  requirement  in  a  way  which  does  not  constrain  the 
implementation  and  does  not  occupy  a  page  of  text  is  beyond  the  author's  current 
ability  in  Z. 

Checking  identifiers  modulo  a  decoration  requires  a  function  to  remove  either  a 
version  or  an  attribute  or  both  from  an  identifier  as  below: 

decchange  ::=  discard  I  keep 
undecorate  s  X  a.  v  :  decchange 
.  X  Id 
•  Id1 

I  name’  =  name  a  synstat’  =  synstat 
a  =  keep  a  att’  =  att 

v  a  =  discard  a  att’  =  noatt 
v  =  keep  a  version’  =  version 

v  v  =  discard  a  version’  =  noname 
.  Bid’ 

An  attribute  or  version  may  only  be  discarded  if  it  is  common  to  a  set  of  identifiers, 
represented  by  the  following  two  schemas: 


common_attr ibute  i  common_vers i on 


ids  :  P  Id 

ids  :  P  Id 

3  att  :  Att 

•  b  ident  :  ids  •  i dent. att  =  att 

3  v  :  Name 
»  b  ident  ;  ids 

»  ident . vers t on  =  v 

Note  that  we  have  stopped  short  of  distinguishing  between  differing  numbers  of 
dashes.  These  two  schemas  may  be  used  to  define  the  function  which  gives  the 
decoration  change  required: 

what_dec  e  X  ids  :  P  Id 

•  m  a.  v  :  decchange 

|  common_attr ibute  a  a  =  discard 

v  '>common_ettr  ibute  a  a  =  keep 
common_vers i on  a  v  =  discard 
v  ',common_vers  i  on  a  v  =  keep 
•  (a.  v ) 

With  this  one  can  define  the  unification  of  schemas  as  follows; 
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m 


M  T'f 


Un i schema 
Uni  pars 


tyl  e  rng  schema_type  a  ty2  a  rng  schema_type 
idsla  =  ids2a 

8Uresult  =  un i f yseqf tenv /  tysa<  tysb ) 
where 

tysl  a  schema_type_1  tyl 

tys2  a  schema_type_1  ty2 

dechl  a  what_dec  dam  tysl 

dech2  a  what_dec  dam  tys2 

idsl  a  order  dom  tysl 

ids2  a  order  dom  tys2 

idsla  a  idsl  l  undecorate  dechl 

ids2a  a  ids2  t  undecorate  dech2 

tysa  a  idsl  i  tysl 

tysb  a  ids2  i  tys2 


Thus  the  specification  for  the  unification  of  non-variable  types  is: 

Non_vars  a  Uni  atoms  v  Undefined  v  Uni  powers  v  Uni  tuples 
v  Un i schema 


with  error  case: 

Typewrong  _ 

Un  i  pars 

-■Non_yars  a  rep!  =  "Incompatible  type"  a  tenv’  =  tenv 

The  various  cases  may  be  collected  together  into  one  schema 

UNIFY  a  Puns  a  ((RHsubs  v  LHsubs  ) 

v  (Novars  a  (Non_vars  v  Typewrong))) 

to  give  a  definition  of  the  unify  function  as: 

d  Unipars  •  BUresult  =  unifyttenv.  tyl/  ty2 )  UNIFY 
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Type  checking  operations 

Type  checking  takes  place  within  the  type  environment  which  gives  the  current 
assignment  of  types  to  names.  For  generic  type  instantiation  it  is  necessary  to  create 
names  unique  to  the  current  type  environment,  so  the  state  for  type  checking 
operations  must  maintain  the  set  of  valid  names. 

^TypeState _ , 

tenv  t  Tenv 
valid_names  :  P  TName 

dom  tenv  C  valid_names 


Finally,  a  general  purpose  operation  to  check  if  two  types  are  the  same: 

TypeChecU  .  _ .  _  . , 

ATypeState;  UNIFY 

valid_names'  =  val id_names 


CHAPTER  5 


NORMALISATION  OF  TYPES 


^datatypes  :Hodule| 

|Z_-type_ un  i  ty  iflodule] 

As  a  result  of  type  checking  operations  the  type  produced  for  an  expression  may 
contain  a  number  of  variables,  all  of  which  should,  at  various  points  in  the  syntax 
such  as  declarations,  have  a  substitution  present  within  the  type  environment. 
Normalisation  is  the  name  used  for  the  process  of  transforming  a  type  by  carrying  out 
the  substitutions  implicit  within  the  environment  and  should  result  in  a  type  containing 
no  variable  elements,  and  in  a  standard  form.  (Note  that  this  use  of  the  term  is 
different  from  the  normal  Z  usage  which  refers  to  the  general  process  of  deriving  a 
type  from  a  term.)  Only  types  which  have  been  normalised  may  be  directly  compared: 
in  all  other  cases  types  should  be  unified  using  the  TypeCheck  operation. 
Normalisation  is  carried  out  using  the  following  function: 

normalise  :  (Type  »  ( TName  Type  ))-•  Type 

This  is  defined  according  to  the  subsets  of  type  as  follows: 

NPars _ _ 

ty  :  Type 

tenv  s  TName  -»» Type 
result  i  Type 


.Nvar 

NPars 


ty  e  rng  var i able 

n  e  dam  tenv  A  result  =  normal i se( tenv  n,  tenv) 
v 

n  e  dam  tenv  a  result  =  ty 
where 

n  s  var  i  able"1  ty 


.  NPowers . 
NPars 


ty  e  rng  powerset 

result  =  powerset(normal i se ( powerset"1  ty,  tenv)) 


Ntuples 

NPars 


ty  e  rng  tuple 

result  »  tupleftuple"1  ty  I  norm) 
where 

norm  a  A  ty  :  Type  •  normal isefty,  tenv) 


22 


_ Nschema 

NPars 


ty  e  rng  schema_type 

result  =  schema_type(schema_type''  ty  i  norm) 
where 

norm  sit/:  Type  •  normal i set ty,  tenv  ) 


_ NAtom 

NPars 


ty  e  AType  a  result  =  ty 


NORH  &  Nvar  v  NPowers  v  Ntuples  v  Nschema  v  NAtom 

W  NPars  •  result  =  normal  i se ( ty .  tenv  )  NORM 

After  normalisation  the  type  should  contain  no  type  variables,  so  define  a  function  to 
count  them: 


names_i  n_type  :  Type—P  TName 


y  ty  :  AType  .  names_i n_type  ty  =  {> 

y  ty  :  rng  variable  •  names_i n_type  ty  =  {variable'1  ty> 
b  ty  :  rng  powerset 

•  names_i n_type  ty  =  names_i n_type(powersef'  ty ) 
y  ty  :  rng  tuple 

.  names_i n_type  ty  =  U  names_i n_typeCrng(  tuple'1  ty  )) 

y  ty  :  rng  schema_type 

«  names_i n_type  ty  =  U  names_in_typefrngCschema_type'1  ty)) 


The  normalisation  operation  must  be  applied  to  all  user-defined  types: 
Normal  i  se _ , 

ty7,  ty!  :  Type 
HTypeState 
rep!  i  seq  Char 


ty!  =  normal isefty?,  tenv) 

*(names_in_type  ty! ) *  *  0 

rep!  ■  "Type  not  completely  specified" 


2_type_norm  keeps  Normalise 
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CHAPTER  6 


REFERENCES  TO  IDENTIFIERS 


|Z_datatypes  iflodulej 
|2_scopes  :Hodule| 

Ordinary  references 


The  syntax  for  references  is: 


reference  = 

id  <reference — type>  ref2» 

id  dir  <check_no_att>  id  <doc_ref erence--type>  ref2; 


A  reference  delivers  a  type  which  is  the  value  of  an  identifier  in  the  current 
environment  (instantiation  is  dealt  with  later).  The  identifier  is  obtained  from  the 
lexical  analyser's  state  variables  and  looked  up  in  the  current  environment  to  find  its 
type. 


_ Tnpld  _ ref_ok 


ALexState 

EEnv 

id!  :  Id 

id7  :  Id;  ty!  :  Type 

id!  =  hd  i dl i St 

id?  e  domtfind  0Env  ) 

idl i st ’  =  tl  i dl i st 

ty!  =  find  0Env  id7 

If  ref_ok  cannot  be  satisfied,  the  identifier  is  undeclared.  This  may  not  be  an  error 
as  there  are  various  identifiers  which  are  conventionally  formed  from  existing 
identifers,  namely  decorated  schemas  and  schemas  used  with  A  and  »•  The  first  use  of 
these  identifiers  when  they  have  not  been  defined,  and  a  schema  of  the  appropriate 
base  name  has,  will  result  in  the  declaration  of  the  appropriate  schema  term.  First  of 
all,  to  express  this,  it  is  necessary  to  define  a  function  to  carry  out  the  decoration 
and  which  expresses  the  rule  that  !,  ?  or  a  version  may  only  be  applied  once. 
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decorate_wi th  _  :  (Name  *  Att  )  -•  ( Id  *♦  Id  ) 


«  new_version  :  Name;  new_att  :  Att 
•  decorate_Hith(new_version,  new_att )  = 

X  Id 

I  new_version  *  noname  version  =  noname 

new_att  e  rng  dashes  att  =  noatt  v  stt  e  rng  dashes 
new_att  =  bang  v  new_att  =  query  — *  att  =  noatt 
.  u  Id' 

|  name’  =  name 

new_version  =  noname  version1  =  version 
new_version  x  noname  — *  version1  =  new_version 
att  =  noatt  -*  att’  =  new_att 
new_att  =  noatt  att’  =  att 
new_att  x  noatt  a  att  x  noatt 

att1  =  dashes  (dashes'1  att  +  dashes'1  new_att  ) 
synstat1  =  synstat 

.  eld1 


Identifiers  beginning  with  A  or  H  which  have  not  been  declared,  but  for  which  a 
schema  definition  for  the  identifier  formed  from  the  name  without  the  initial  Greek 
letter  exists  will  have  a  new  schema  definition  created  automatically.  The  new  schema 
involves  decoration  with  a  dash,  and  the  schema  must  be  capable  of  being  decorated 
in  this  way: 


b 


der  i  ved_i  d 
j  HEnv 

I  id?,  id!  :  Id;  ty!  ;  Type 


first_char  =  ’A’  v  first_char  =  ’ E' 
id*  e  domtfind  eEnv ) 

ty'  e  rn9  powerset  a  powerset'1  ty’  e  rng  schema_type 
dom  ids  C  dom  decorate 
ty!  =  powerset (schema_type  ids') 
id!  =  id? 
where 

first_char  s  hdtline'1  id?. name). 1 
id’  £  p  Id 

I  name  =  1  inetedecl ine'  ) 
where 

I  ^decline 


ISdecline  =  line"1  id?,  name 

1'  =  tl  1  A  W’  =  W 

version  =  id?. vers  ion 
att  =  id?.att  a  synstat  =  id?.synstat 
.  eld 

ty'  £  find  eEnv  id’ 
ids  £  schema_type'1(  powerset'1  ty’  ) 
decorate  £  decorate_wi thtnoname.  dashes  1) 
ids'  £  -Cid’  :  Id;  ty  :  Type 
I  3  ident  :  dom  ids 

I  id’  =  decorate  ident  .  ty  =  ids  ident 
•  id’  »  ty 
> 


The  same  possibility  for  implicit  declaration  exists  for  an  undeclared  identifier  with  a 
decoration,  if  a  schema  definition  exists  for  the  undecorated  identifier.  Note  that  for 
reasons  of  simplicity  the  view  has  been  taken  that  the  base  name  version  must  have 
been  defined,  which  precludes  the  decoration  of  an  imported  schema  if  the  defining 
document  has  been  renamed,  because  this  simply  imports  the  decorated  names.  As 
with  the  derived  schema,  the  decorated  schema  must  be  capable  of  being  decorated 
in  the  way  required. 
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—  decor  ated_id 
1  HEnv 

I  id?/  id!  :  Id;  ty!  :  Type 


ident  e  domtfind  0Env ) 

ty  e  rng  powerset  a  powerset'1  ty  e  rrt9  schema_type 
dom  ids  C  dom  decorate 
ty!  =  powerset (schema_type  ids’  ) 
id!  =  id? 
where 

ident  £  y  Id 

I  name  =  id?. name 
version  =  noname 

att  =  noatt  a  synstat  =  id7.synstat 
.  6ld 

ty  £  find  eEnv  ident 
ids  £  schema_type'1(powerset'1  ty  ) 
decorate  £  decor ate_w i th( id?- vers  ion ,  id?. att) 
ids'  £  fid'  :  Id!  ty  :  Type 
I  3  ident  :  dom  ids 

I  id’  =  decorate  ident  •  ty  =  ids  ident 
•  id'  «  ty 
> 


All  error  cases  are  treated  as  an  undeclared  identifier,  which  is  a  bit  unfriendly  in 
the  case  of  incompatible  decorations: 

ref_wrong _ 

HEnv 

id?/  id!  :  Id;  ty!  :  Type 
rep!  :  seq  Char 


-•(decor8ted_id  v  derived_id) 
rep!  =  "Identifier  undeclared" 
ty!  *  type_undef ined 
id!  =  id? 


For  the  three  undeclared  cases,  it  is  necessary  to  ensure  that  the  identifier  created 
is  declared,  so  that  a  subsequent  declaration  will  be  ignored  and  not  give  rise  to 
inconsistency. 

_ dec i d  _ 

OecI.retty?/ty] 

1  id?  i  Id;  ty!  ;  Type 


new_ids  ■  (id?)  a  ty!  *  ty? 


undeclared  •  (derived_id  v  decorated_id  v  ref_Hrong)  > 
decid\(rep!,  new_ids) 
reference  •  Topld  >  (undeclared  a  ref_ok  ) 
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A  decoration  may  also  be  applied  to  a  schema  term  in  the  following  situation,  where 
spec_sexpZ  is  a  syntax  rule  occuring  in  the  expansion  of  the  rules  for  special 
purpose  schema  expressions. 


rename  = 

lsqb  rename_list  rsqb  < id_inst-ptype-p i nstant i at i on — type>. 
decor  <decorate-ptype — type>; 

spec_sexp2  = 

lpar  schema_term  rpar. 
lpar  schema_term  rpar  rename, 
reference  <check_schema-ptype — type>. 
schema) 


The  compiling  functions  is  a  simple  variation  of  the  above:  the  decoration  required  is 
found  in  an  identifier  left  at  the  head  of  the  lexical  analyser's  queue. 


_ decor ate_ok 


id?  :  Id 
ty?.  ty!  :  Type 
rep!  :  seq  Char 

ty!  =  powerset(schema_type  ids’) 
dom  ids  c  dom  decorate 
where 

ids  a  schema_type"‘(  power  set"1  ty?) 
decorate  a  decorate_w i th( i d?. vers i on . 

d7. att ) 

ids'  a  -Cid’  :  Id)  ty  :  Type 
|  3  ident  :  dom  ids 

I  id’  =  decorate  ident  .  ty  = 

ids  ident 

•  id'  ty 

> 

1 

The  only  error  case  occurs  with  incorrect  decorations  as  the  syntax  ensures  that  the 
type  of  a  schema  term  is  always  a  schema  type. 


_ decor ate_wrong  . 

id?  :  Id 
ty?.  ty!  :  Type 
rep!  :  seq  Char 


ty!  =  ty? 

-’(dom  ids  c  dom  decorate)  — *  rep!  =  "Incorrect  decoration" 
where 

ids  a  schema_type‘'(  power  set"1  ty?  ) 

decorate  a  decorate_with( id?. version.  id7.att) 


decorate  *  Topld  >  decorate_ok  v  decorate_wrong 
Document  references 


Document  references  are  preceded  by  a  document  name,  which  must  contain  no 
attributes.  If  they  are  present  an  error  is  reported  and  they  are  discarded. 
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check _no_att  _ 

j  ALexState 

rep!  :  seq  Char 


(hd  idlist  ).att  =  noatt  idlist’  =  idlist 
(hd  idlist  ).att  y  noatt 

rep!  =  "Document  reference  may  not  contain  attributes" 
hd  idlist’  =  p  Id 

|  name  -  i dent. name 

version  =  i dent . vers i on 
att  =  noatt 

synstat  =  ident.synstat 
where 

i dent  £  hd  idlist 
.  9 Id 

t 1  idlist’  =  t 1  idlist 


1  ALex 

State 

1 

doc ! 

:  Id 

id! 

=  idli 

st (2 )  a  doc !  = 

idli st ( 1  ) 

i  dl  i 

st’  = 

1 1 C 1 1  idlist) 

doc 

ref  ok 

EEnv 

id ?, 

doc7 

:  Id 

ty ! 

:  Type 

(8En 

v,  doc?)  e  dom  find_ 

doc 

id? 

e  dom( 

f ind_doc CeEnv > 

doc?  ) ) 

ty ! 

=  fine 

_docC8Env»  doc?)  id7 

If  the  identifier  is  not  present  in  the  document  an  error  is  reported  without 
attempting  to  look  for  decorated  versions:  this  is  a  somewhat  debateable  decision. 

doc_ref_wron9  t 

EEnv 

id?»  doc?»  id!  :  Id 
ty!  :  Type 
rep!  :  seq  Char 


(8Env/  doc?)  t  dom  find_doc  a  rep!  =  "No  such  document" 
v 

CeEnv/  doc?)  e  dom  find_doc 
a  id?  d  domtf ind_doc(8Env/  doc?)) 
a  rep!  *  "Identifier  undeclared" 
ty!  *  type_undef ined 
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doc_reference  *  Toplds  >  (doc_ref_ok  v  doc_ref_wron9 )  > 

decid\(rep!<  new_ids) 

Z_references  keeps  reference#  decorate.  check_no_att . 
doc_reference 
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CHAPTER  7 


ANONYMOUS  INSTANTIATION 

|Z_datatypes  ;Hodule| 
j2_scopes  t  Module] 

|2_type_un  i  fy  : Module] 

The  relevant  extract  from  the  syntax  is: 


reference  = 

id  <reference — type>  ref2, 

id  dir  <chect<_no_att>  id  <doc_reference — type>  ref2; 
ref2  = 

<anon_i nst-ptype — type> . 

instantiation  <i d_i nst-ptype-p instantiation — type>; 


For  anonymous  instantiation,  the  input  type  ty7  will  be  the  type  of  the  identifier  as 
given  by  the  identifier  environment:  the  output  type  ty!  is  the  instantiated  type, 
which,  if  the  type  is  generic,  must  be  suitable  for  the  application  of  the  type 
inference  rules.  Consequently  it  is  necessary  to  find  the  generic  identifiers  within  the 
type.  This  is  slightly  complicated  by  the  fact  that  at  a  defining  occurence  of  an 
identifier,  for  example  the  predicate  part  of  an  axiomatic  definition,  types  dependent 
on  the  generic  parameters  should  not  be  instantiated  at  differing  types.  If  this  rule  is 
not  followed,  it  is  possible  to  create  some  inconsistencies.  For  example,  defining  a 
generic  function  f  •.  S-.T,  where  S  and  T  are  generic,  should  result  in  an  error  if 
the  predicate  contains  f  =  X  s  :  S  .  s,  as  the  delivered  type  must  be  the  same  as 
the  parameter.  Within  a  generic  definition,  the  identifiers  for  the  generic  parameters 
are  still  in  scope,  so  this  gives  a  test  as  to  which  generic  types  should  be  instantiated 
as  variables  and  which  should  not:  the  true  generics  are  those  which  appear  in  the 
type,  but  are  not  currently  defined  within  the  environment.  The  effect  of  this  rule  is 
that  generic  schemas  used  as  an  inclusion  within  a  generic  schema  definition  which  is 
generic  in  the  same  identifiers  will,  if  instantiated  anonymously,  be  treated  as  the 
same  generic  parameters.  The  effect  is  as  if  the  new  generic  definition  extends  the 
old  one,  which  is  probably  what  is  intended. 

Note  that  variable  types  are  only  created  for  the  purposes  of  anonymous  instantiation, 
so  that  the  type  derived  from  the  identifier  environment  and  supplied  by  reference 
will  contain  no  variable  component.  This  is  checked  using  the  type  normalisation 
function  (see  chapter  5)  which  is  always  used  prior  to  declaring  an  identifier  with  a 
given  type.  First  of  all  then,  a  function  to  give  the  true  generics  within  a  type: 
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ids_in_type  :  (Env  *  Type)-»P  Id 


W 


env  :  Env 

d  ty  :  rng  generic 

•  ident  e  generic_ids  a  ids  ty  =  (> 

v  ident  t  generic_ids  a  ids  ty  =  (ident> 
where 


ident 

:  Id 

3  n  : 

N  •  ty  =  gener ic(n,  ident) 

y  ty  :  AType  \  rng  generic  •  ids  ty  =  (> 
y  ty  :  rng  powerset  •  ids  ty  =  i  dstpowerset"1  ty  ) 
y  ty  :  rng  tuple  •  ids  ty  =  U  i  ds  Crng(  tuple'1  ty  )) 
y  ty  ;  rng  schema_type 

•  ids  ty  =  U  i  ds  (rng  ( schema_type'’  ty)) 
where 

ids  S  X  ty  :  Type  •  i ds_in_type(env,  ty ) 


generic_ids  a  -(ident  :  Id 
I  3n  :  N 

•  find  env  ident  = 

powerset (gener ic(n. 

> 


i dent  )  ) 


The  instantiation  of  a  non-generic  variable  is  straightforward: 


Non_gen_var  _ 

ETypeState 

EEnv 

ty? i  ty!  :  Type 


ids_in_type(9Env,  \yl )  =  (> 
ty!  =  ty? 

1 

For  generics  we  need  a  mapping  from  the  generic  identifiers  to  a  unique  set  of  names, 
not  currently  existing  within  the  environment: 

Newnames  i 

ATypeState 

EEnv 

ty?  :  Type 
sub!  :  Id~»TName 


tenv  *  tenv’ 

dom  sub!  *  i ds_i n_type( 0Env ,  ty? ) 
rng  sub!  n  valid_naines  =  O 
vslid_nsmes’  *  val id_names  U  rng  sub! 


Given  a  mapping  from  identifiers  to  names,  the  following  function  produces  a  variable 
type  from  a  generic: 
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inst_type  (Type  *  ( Id -»*TName  ) ) -**Type 


y  s  :  Id-»TName 
•y  ty  :  rng  9eneric 

•  ident  e  dom  s  A  inst_type(ty,  s)  =  variablefs  ident) 
v  ident  t  dom  s  a  inst_type(ty,  s )  =  ty 

where 


ident 

!  Id 

3  n  : 

H  •  ty  =  genericln,  ident) 

y  ty  :  AType  \  rng  generic  •  inst_type(ty,  s  )  =  ty 
y  ty  :  rng  powerset 

•  inst_type(ty*  s)  =  powerset ( inst_type(powerset''  ty,  s)) 
y  ty  :  rng  schema_type 

•  i nst_type( ty ,  s)  =  schema_type(  schema_type''  ty  }  inst) 
where 

inst  s  X  ty  :  Type  •  inst_type(ty ,  s) 
y  ty  :  rng  tuple 

.  i nst_type( ty ,  s)  =  tuple(tuple"'  ty  J  inst) 
where 

inst  2  X  ty  :  Type  .  inst_type(ty,  s) 


which  may  be  used  to  create  the  new  type  from  the  one  given  by  reference: 

Gen_var _ , 

ETypeState 
sub?  :  Id^TName 
ty?,  ty!  :Type 


ty!  =  inst_type(ty?,  sub9) 


The  total  operation  for  anonymous  instantiation  is 

anon_inst  2  Non_gen_var  v  (Newnames  >  Gen_var ) 
Z_anon_inst  keeps  anon_inst,  ids_in_type 
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CHAPTER  8 


FORMATION  OF  INSTANTIATIONS 


|Z_datatypes  : Module] 
jZ_scopes  :f1odule| 

|Z_references  :  Module] 

|Z_type_norm  :!1odule| 

Named  instantiation  is  applied  to  identifiers  having  a  generic  type  and  brings  about 
the  replacement  of  the  generic  components  in  the  type  of  the  identifier  with  the 
types  given  for  this  particular  use  of  the  identifier.  The  given  types  may  be 
introduced  in  the  form  of  a  list  of  types,  in  which  case  the  generic  components  are 
given  by  the  order  in  which  they  were  introduced  in  the  generic  definition  which 
assigned  a  type  to  the  identifier,  or  they  may  be  introduced  as  a  mapping  between 
identifiers  and  types,  to  indicate  which  particular  generic  component  is  to  be 
instantiated.  Because  of  the  syntactic  difficulties  of  distinguishing  between 
instantiation  and  schema  renaming  (both  begin  with  an  opening  square  bracket  and  can 
carry  on  with  an  identifier),  both  are  treated  as  belonging  to  the  same  syntactic  class, 
so  the  representation  of  an  instantiation  must  cover  both  possibilities.  This  leads  to 
the  following  datatype  definition  for  the  representation  of  an  instantiation: 

Instantiation  ::=  ter m_l i stCseq  Type»  I  b i nd i ng_l i st«Id «• Type» 

I  rename_l  i  st«Id -►»  Id» 

The  relevant  syntax  for  the  formation  of  a  term  list  instantiation  is: 


instantiation  =  lsqb  inst_list  rsqb; 

inst_list  =  i nst_term_l i st .  b i nd i n9_l i st ,  rename_list; 

••gathered  together  to  resolve  various  one-track  problems** 

i nst_term_l i st  = 

term  <tmll-ptype — i  nstant i at i on> , 

term  <tmll-ptype — i nstant i at i on>  comma  i nst_terml i st 1 ; 
i nst_terml i st 1  = 

term  <tml2-ptype-p i nstant i at i on — i nstant i at i on >  i nst_terml i st2 ; 
i nst_terml i stZ  =  $»  comma  inst_terml istl; 


The  compiling  functions  tmll  and  tmlZ  form  the  instantiation  from  the  component 
terms,  each  of  which  must  stand  for  a  type.  This  is  because  the  generic  identifiers 
have  powerset  type  so  that  they  may  be  used  in  a  signature  and  consequently  they 
may  only  be  instantiated  as  sets.  This  is  checked  in  the  operation  below,  which 
removes  the  powerset  constructor  to  form  the  type  which  will  be  stored  in  the 
instantiation. 

Check  _typen  ( 

ty?.  ty!  :  Type;  rep!  :  seq  Char 


ty?  e  rng  powerset  a  ty!  =  powerset'1  ty? 
v 

ty?  t  rng  powerset  a  ty!  *  ty? 

a  rep!  ■  "Incorrect  type  for  instantiation" 
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As  well  as  this  check,  the  view  has  been  taken  that  instantiations  ought  to  be 
defined,  as  otherwise  it  would  be  possible  to  instantiate  a  generic  term  with  the 
empty  set  for  example.  Consequently  an  additional  check  is  made  to  ensure  that  the 
type  is  normalised. 

Check_type  a  Normalise  >  Check_typen 
The  operation  tmll  forms  the  first  element  in  the  term  list  instantiation: 

—  tmlla _ _ 

I  ty?  :  Type;  inst!  :  Instantiation 


inst!  =  term_list  (ty9) 


tmll  a  Check_type  >  tmlla 

while  tml2  is  for  subsequent  elements 

tmlZa  _ 

I  ty?  :  Type;  inst7.  inst!  ;  Instantiation 


inst!  =  term_l  i  st  ( term_l  i  st'1  inst?  snoc  ty7  ) 


tml2  a  Check_type  >  tml2a 
There  are  similar  operations  for  binding  lists  and  rename  lists: 


binding_list  =  bll»  bll  comma  b indi ng_l i st 1 ! 
bll  = 

id  equals  <bll — id>  term  <bl2-p i d-ptype — instantiation); 

binding_l istl  = 

bl2.  blZ  comma  b i nd i ng_l i st 1 ; 

blZ  = 

id  equals  <bll — id>  term 

<bl3-p i d-ptype-p instantiation —  instantiation); 


ALexState 
id!  :  Id 

id?  : 
inst ! 

Id;  ty?  :  Type 
:  Instantiation 

id!  *  hd 
idl i st ’  - 

dl 

tl 

st 

idl ist 

—  ,  —  ■  J 

inst ! 

=  binding_list  {id?  »  ty?> 

blZ  a  Check_type  >  bl2a 


Note  that  a  compiling  function  bll  is  required  because  the  term  may  alter  the 
identifier  queue.  For  subsequent  terms  in  the  binding  list,  a  binding  mentioning  the 
same  identifier  twice  is  ignored  and  an  error  reported. 


bl3a 

id? 
rep! 


Id;  ty?  :  Type: 
1  -  seq  Char 


inst?.  inst!  :  Instantiation 


id?  t  dom  tys  a  inst!  =  b i nd i ng_l i st ( tys  U  -Cid7  h>  ty7>  ) 
v 

id?  e  dom  tys  a 

rep!  =  "Identifier  occurs  twice"  a  inst!  =  inst7 

where 

tys  a  b i ndi n9_l  i st*‘  inst? 


bl3  a  Check_type  >  bl3a 

Compiling  a  rename  list  is  easier  because  only  identifiers  are  involved. 


rename_list  = 

id  for  id  <rnll — i nst ant i at i on > . 

id  for  id  <rnll — i nstant i at i on >  rename_l i st 1 ; 

rename_listl  = 

id  for  id  <rn 12-p i nstant i at i on — i nstant i at i on >  rename_l i st2 ; 
rename_list2  =  $»  comma  rename_l i st 1 ; 


rnll  _ 

ALexState 

inst!  ••  Instantiation 


inst!  =  rename_list  -Cidlist(l)  -  idlist(2)> 
i dl i st ’  =  1 1 ( 1 1  i dl i st  ) 


Various  obvious  error  cases  are  dealt  with  in  the  compiling  function  for  subsequent 
elements  in  the  rename  list. 

_ rnlZ _ i 

ALexState 

inst?.  inst!  :  Instantiation 
rep!  ;  seq  Char 


idlist(l)  t  dom  idmap  a  i dl i st  C  Z  )  *  rng  idmap  a 

inst!  =  rename_l i st ( i dmap  U  •Cidlist(l)  ~  idlistCZ)}) 
v 

i dl i st  Cl)  e  dom  idmap  a 

rep!  =  "Identifier  occurs  twice"  a  inst!  =  inst? 
v 

idl  st(2)  e  rng  idmap  a 

lap!  =  "Coincidental  renaming"  A  inst!  =  inst? 

where 

idmap  e  rename_l  i st*1  inst? 
i dl i st ’  =  1 1 ( 1 1  idl i st  ) 
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V 


2_mk_instsnt iat ion  keeps  Instantiation,  term_list<  binding_list. 

rename_list.  Check_type,  tmll,  tm!2, 
bll,  b!2,  b!3 ,  rnll,  rn!2 


\ 


k 
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CHAPTER  9 


NAMED  INSTANTIATION 


|Z_datatypes  Module) 
jZ_scopes  :  !1odule| 

|Z_ink_i nstant  i at  i on  ;  Module] 
|Z_anon_inst  ;Module) 


The  relevant  syntax  is  that  associated  with  references: 


reference  = 

id  <reference — type>  ref2, 

id  dir  <check_no_att>  id  <doc_ref erence — type>  ref2; 
ref2  = 

<anon_i nst-ptype — type> , 

instantiation  < i d_inst-ptype-p i nstant i at i on — type>; 


There  are  three  similar  cases  for  named  instantiation,  depending  on  the  type  of  the 
instantiation.  Note  that  as  a  result  of  combining  schema  renaming  with  instantiation  it 
is  possible  to  rename  a  schema  within  an  inclusion,  which  turns  out  to  be  a  useful 
facility,  so  it  has  not  been  disallowed. 

Two  functions  will  be  defined  which  carry  out  term  list  and  binding  list  instantiation. 
They  are  very  similar  and  may  be  defined  according  to  the  elements  of  type.  First  of 
all,  a  function  for  term  list  instantiation: 


"■  ■■  .  —  -  — .  ■  ■  .  . - . -t 

tl_inst  :  (Type  *  seq  Type)-»Type 


W  ty.  result  :  Type;  s  :  seq  Type 

I  result  =  tl_inst(ty,  s) 

•  3  ident  ;  Id;  n  :  N  |  ty  =  genericfn,  ident  ) 

•  n  e  dom  s  — ►  result  =  s  n 
n  t  dom  s  — *  result  =  ty 
v 

ty  e  AType  \  m9  generic  a  result  =  ty 
v 

ty  e  rng  powerset 

a  result  =  powerset(tl_inst(powerset''  ty,  s)) 

V 

ty  e  rng  tuple 

result  =  tuplettys  ;  inst) 
where 

tys  £  tuple'* 1 * * * V  ty 

inst  fi  A  ty  :  Type  .  tl_inst(ty,  s) 
v 

ty  e  rng  schema_type 
result  =  schema_type( tys  ;  inst) 
where 

tys  £  schema_t ype'1  ty 

inst  £  A  ty  j  Type  .  tl_inst(ty,  s) 


Binding  list  instantiation: 
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-  =  S  -  - . .  =q 

bl_inst  :  (Type *  *  ( Id -wType  ) ) -»Type 


y  ty»  result  :  Type;  s  :  Id-»Type 
I  result  =  bl_inst(ty,  s) 

•  3  ident  :  Id;  n  :  N  I  ty  =  generictn,  ident) 

•  ident  e  dom  s  — ►  result  =  s  ident 
ident  £  dom  s  -♦  result  =  ty 
v 

ty  e  AType  \  rn9  generic  a  result  =  ty 
v 

ty  e  rng  powerset 

a  result  =  powersetCbl^nstCpowerset"1  ty,  s)) 
v 

ty  e  rng  tuple 
result  =  tuple(tys  1  inst) 
where 

tys  S  tuple'1  ty 

inst  &  X  ty  :  Type  •  bl_inst(ty<  s) 
v 

ty  e  rng  schema_type 
result  =  schema_type(tys  ;  inst) 
where 

tys  s  schema_type'‘  ty 

inst  s  X  ty  ;  Type  •  bl_inst(ty>  s) 


The  function  for  schema  renaming  is  an  extended  composition; 


schema_rename_  s  ((Id-»Type)  *  ( Id -»♦  Id  ) ) -«  ( Id Type  ) 


d  schema_ids  :  Id « Type;  i dmap  :  Id-»Id 

•  schema_rename(schema_ids>  idmap)  =  idmap’  ;  schema_ids 
where 

idmap'  S  X  ident  :  Id 

•  u  ident'  :  Id 

I  ident  e  dom  idmap  ident’  =  idmap  ident 

ident  £  dom  idmap  ident’  =  ident 

•  ident’ 


The  operation  for  instantiation  checks  error  cases,  but  instantiates  as  many  types  as 
are  correct. 
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b 


inst?  e  rng  term_list 
ty!  *  tl_inst(ty?,  s) 
adorn  s  >  *( i ds_i n_type( 8Env>  ty?))  —* 
rep!  =  "Too  many  terms" 

where 

s  £  term_list'*  inst? 
v 

inst?  e  rng  binding_list 
ty!  =  bl_inst(ty?<  s) 

-"(dom  s  C  i ds_in_type( 0Env>  ty?  ) )  — ► 

rep!  =  "Not  generic  in  this  identifier" 

where 

s  fi  binding_l  ist*1  inst? 


while  that  for  schema  renaming  is 

_ rename _ 

EEnv 

ty?,  ty!  :  Type 
inst?  :  Instantiation 
rep!  !  seq  Char 


inst?  e  rng  rename_list 

-"Schema  a  ty!  =  ty?  a  rep!  =  "Only  schemas  may  be  renamed” 
v 

bad_ids  *  {> 

rep!  =  "Identifiers  not  defined  in  this  schema" 

ty!  =  power set (schema_t ype  schema_rename( ids,  good_ids)) 
where 

ids  £  schema_type',(powerset-'  ty?) 
idmap  s  rename_l  i st'1  inst? 
bad_ids  £  rng  idmap  \  dom  ids 
good_ids  £  idmap  t>  dom  ids 


After  named  instantiation  or  schema  renaming,  any  generic  types  remaining  are 
instantiated  anonymously: 


id_inst  £  (inst  v  rename)  »  anon_inst 
Z_pamed_i nst  keeps  id_inst,  inst 
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CHAPTER  10 


GIVEN  SET  DEFINITIONS  AND  GENERIC  PARAMETERS 

|2_datatypes  -.Modulel 
|Z_scopes  ; Module | 

Given  set  definitions 


The  syntax  for  given  set  definitions  is  very  simple: 


9 i ven_set_def  =  lsqb  given_ids  rsqb; 

9iven_ids  =  id  <g i ven_set_def > <  given_idsl; 
given_idsl  =  $»  comma  given_ids; 


The  rule  given„ids  is  also  used  for  the  parameters  in  generic  definitions.  Given  set 
identifiers  and  generic  parameters  must  be  unique  within  the  current  scope  and  are 
not  allowed  to  have  attributes  or  versions.  This  is  partly  because  of  the  form  chosen 
for  the  syntactic  status  of  generic  sets,  but  it  does  seem  to  be  a  reasonable 
restriction. 

check  _gi  ven_id _ , 

OLexState 
rep!  :  seq  Char 
ident!  :  Id 


ident.att  *  noatt  v  ident. version  *  noname  -* 

rep!  =  "Parameter  identifiers  may  not  be  decorated” 
ident!  *  y  Id 

|  name  =  ident. name  a  version  =  noname 
a  att  =  noatt  a  synstat  =  i dent . synstat 

.  eld 

where 

ident  &  hd  idl ist 
i dl i St '  =  1 1  i dl i st 


g i ven_set_error 
HEnv 

ident?  :  Id 
rep!  :  seq  Char 


ident?  c  dom  (hd  blocks). ids 

rep!  *  "Identifier  for  given  set  already  declared" 


The  type  of  T  in  [T]  is  just  powerset  of  given  of  T  in  the  outermost  block,  or 
generic  of  T  in  an  inner  block,  combined  with  the  serial  number  to  allow  for 
sequential  instantiation.  The  global  scope  is  detected  by  the  fact  that  there  is  only 
one  block  in  the  environment. 
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9 i ven_set_ok 

Env;  Env’ 
ABlock 
ident?  :  Id 


SBlock  =  hd  blocks  a  eBlock'  =  hd  blocks’ 
tl  blocks  =  tl  blocks' 
docs’  =  docs  a  docnames'  =  docnames 
st’  =  st 

last_gener ic’  =  last_generic  +  1 
ident?  t  dom  ids 

ids’  =  -(ident?  ty>  U  ids 
where 

I  ty  :  Type 


••blocks  =  1  — *  ty  *  powerset (g i ven  ident?) 
••blocks  >  1  —* 

ty  =  powerset ( gener ic( last  generic*,  ident*7)) 


In  this  schema,  it  has  been  necessary  to  expand  declare,  because  of  the  change  to 
gener  i  cs. 

g i ven_set_def  a  cheeky  i  ven_id  > 

(g i ven_set_error  v  9 i ven_set_ok  ) 


Generic  definitions 


For  generic  parameters  an  extra  scope  is  introduced  to  contain  the  identifiers  and 
their  types: 


lgen_params  =  glsqb  <new_scope>  9iven_ids  rsqb: 


A  further  scope  is  created  to  contain  the  newly  declared  identifiers,  after  which  the 
usual  declaration  and  definition  functions  (see  later)  are  used: 


gener ic_def  = 

I  9lobal_id  <stert_idl ist — i dl i st >  gen_psrams  <new_scope> 
colon  term  <dec_ids-pidl ist-ptype> 
ebar  pred  <unstack_pred-ptype><end_sen_def > > 
sr  9en_params  <new_scope>  ge  defjoody  er  <end_gen_def >; 


At  the  end  of  the  generic  definition  the  current  scope  is  merged  with  the  outer  one 
and  the  generic  parameter  scope  thrown  away: 
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scope_to_ids 
Env;  Env' 

merge_ids  :  Id-»Type 
mtuple  :  seq  Type 


merge_tds  =  (hd  blocks). ids 
m_tuple  =  (hd  blocks  ). ctuple 
blocks'  =  tl(tl  blocks) 
docs’  =  docs 
docnames'  =  docnames 


.  Merge_ids _ 

Merge 

m_tuple  :  seq  Type 


ctuple'  =  ctuple~m_tuple 


The  characteristic  tuple  will  not  be  used  at  the  global  level,  but  the  declarations 
are  appended  here  for  consistency. 


end _gen_def  a  ( scope_to_i ds  J  Merge_ids )\(merge_ids.  m_tuple ) 
Z_given_£ets  keeps  gi ven_set_def .  end_gen_def 
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CHAPTER  11 


DECLARATIONS  AND  INCLUSIONS 


[Z_datatypes  :t1odulej 
|Z_scopes  ; Module] 
|Z_type_norm  :  Module] 

Declarations 


The  commonest  form  of  definition  is  the  declaration,  which  appears  in  the  form  of  a 
declaration  list,  repeatedly  throughout  the  syntax.  The  syntax  for  a  declaration  is 
as  follows: 


dec  =  id_list  colon  term  <dec_i ds-p i dl i st-ptype> ; 
i d_l i st  = 

id  <start_i dl i st — i dl i st > # 

id  <start_i dl i st  —  i dl i st >  comma  idlistl; 

i dl i st 1  = 

id  <stack_idl ist-pidl ist — i dl i st > * 

id  <stack_i dl i st-p i dl i st — i dl i st  >  comma  idlistl; 


The  declaration  gives  a  list  of  identifiers  and  a  term  to  define  their  type.  As  term 
may  alter  the  lexical  state,  it  is  necessary  to  stack  the  identifier  list,  rather  than 
using  the  lexical  analyser's  queue  of  identifiers: 


ALexState 

idlist!  : 

seq 

Id 

idlist!  = 

<hd 

idlist) 

idlist'  = 

tl 

dl  i  st 

■  .  -i 

The  stacking  function  checks  for  repeated  identifiers: 

_ stack_idlist  _ 

ALexState 

idlist?,  idlistl  :  seq  Id 
rep!  :  seq  Char 


ident  e  rng  idlist? 

idlist!  =  idlist?  *  rep!  =  "Identifier  declared  twice" 
ident  t  rng  idlist? 

idlist!  =  idlist?  snoc  ident 
idlist'  =  tl  idlist 
where 

i dent  s  hd  idlist 


The  identifiers  may  be  declared  if  the  term  in  the  declaration  specifies  a  type  and 
the  type  is  compatible  with  the  syntactic  status  of  the  identifier.  In  the  standard 
syntax  the  syntactic  status  may  only  be  set  for  a  global  identifier  and  this  rule  has 
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been  followed  in  the  syntax  given  here.  However  the  same  compiling  function  is  used 
for  global  and  local  declarations  so  the  generalisation  of  this  rule  would  be  a 
syntactic  change  only.  In  checking  the  syntactic  status,  it  is  necessary  first  of  all  to 
check  that  the  syntactic  status  of  the  identifier  is  compatible  with  the  other  members 
of  the  list  of  identifiers  being  declared.  For  this  the  arity  of  the  function  is  needed 
and  an  indication  of  whether  the  identifier  is  to  be  a  relation  or  not.  This  is  given  as 
an  integer  by  the  following  function. 

arity  S  )i  Id  •  m  n  :  0.  •  3 

I  synstat  =  ident  — »  n  =  0 

synstat  =  preop  v  synstat  =  postop 
v  synstat  e  rn9  encop  — »  n  =  1 
synstat  =  op  v  synstat  e  rng  distinop 
v  synstat  e  rns  distpreop  — ♦  n  =  2 
synstat  =  rel  n  =  3 
•  n 

The  check  for  correct  status  is  given  by 


_ status_ok 


idlist?  : 

seq  Id 

n  !  0.  .  3 

ty? .  ty! 

Type 

n  =  arityChd  idlist7) 

d  ident  ! 

rn9  idlist?  •  arity  ident  =  n 

ty!  =  ty? 

with  error  case: 

status__error _ 

i dl i st?  :  seq  Id 
rep!  :  seq  Char 
n  i  0..3 
ty?.  ty!  :  Type 


n  =  aritylhd  idlist7) 

Md  ident  :  rng  idlist?  «  arity  ident  =  n) 
rep!  =  "Mixture  of  operator  symbols" 
ty7  =  type_undef i ned 


No  corrective  action  is  taken  to  remove  consequential  errors.  The  type  check  takes 
place  after  normalisation  so  the  test  for  correct  type  need  not  take  account  of  type 
variables. 
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_type_ok  _ . — 

n  :  0..3;  ty?.  ty!  :  Type 


n  =  0  a  ty?  e  rn9  powerset  a  ty!  =  ty9 
v  n  =  1 

3  tyl.  tyZ  :  Type 

•  ty?  =  powerset(powerset(tuple(tyl.  ty2>)) 
ty!  =  ty? 

v  n  =  2 

3  tyl.  tyZ.  ty3  :  Type 

.  ty?  =  powerset(powerset(tuple<tuple<tyl.  ty2>.  ty3>)) 
ty!  =  ty? 
v  n  *  3 

3  tyl.  tyZ  :  Type 

•  ty?  =  powerset (powerset  ty’  ) 

ty!  =  powerset (powerset (tuple<ty‘ »  predicate))) 
where 

ty’  £  tuple<tyl»  ty2> 


In  the  error  case  the  symbols  will  be  declared  with  undefined  type,  to  reduce 
consequential  errors: 

_ type_error  _ _ 

rep!  :  seq  Char 
n  :  0. .3;  ty7.  ty !  :  Type 


-•typejk 

n  *  0  -•  rep!  =  "The  term  given  is  not  a  type" 
n  *  0  — *  rep!  =  "Inappropr i ate  type  for  operator  symbol" 
ty!  =  powerset  type_undef i ned 


The  declaration  is  simply  given  by 

_ declare_ids  _ 

Declaret  jdljst,/new_ids] 
ty7  !  Type 


ty?  €  rng  powerset  a  ty  =  powerset"1  ty? 

_ . _ i 


and  the  compiling  function  by 

dec_i ds  »  (status_error  v  status_ok  )  »  Normalise  > 
(type_error  v  type_ok  )  >  declare_i ds\( ty  ) 


Inclusions 


inclusion  =  reference  <open_schema-pt ype>; 


For  schema  inclusions  it  is  simply  necessary  to  merge  in  the  schema  identifiers  into 
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the  current  environment,  after  checking  that  the  reference  is  to  a  schema  and  that 
it  does  not  have  an  undefined  type. 

__  include_schema _ _ 

Schema;  Include 


mer9e_ids  =  schema_type'Hpowerset''  ty?  ) 


not_schema_ter m 
t y9  :  Type 
rep!  :  seq  Char 


■•Schema 

rep!  =  “Not  a  schema  term" 


open_schema  a  Normalise  >  ( i nclude_schema\(merge_i ds  ) 

v  not_schema_term 

) 

A  schema  inclusion  may  also  appear  in  a  hypothesis  where  it  appears  syntactically  to 
be  a  predicate: 


hyp  = 

pred  <check_pred_schema-ptype> , 
sdec_list  cbar  pred  <unstack_pred-ptype>; 


The  allowable  types  for  a  predicate  at  this  point  in  the  syntax  are  predicate,  the 
undefined  type  or  a  schema;  if  it  is  not  one  of  those,  an  error  is  reported.  If  it  is  a 
schema  then  it  is  included. 

.-Pred - , 

t y9  :  Type 
rep !  :  seq  Char 


ty?  =  predicate  v  t y9  =  type_undef ined  v  not_schema_term 


Note  that  predicates  should  contain  no  type  variables,  so  the  type  must  be  normalised 
to  give  a  specification  for  the  compiling  function  as 

check _pred_schema  *  Normalise  > 

(pred  v  ("'pred  a  include_schema\(merge_i ds  ) ) ) 
H_dec_end_i nc  keeps  start_idl ist.  stack_i dl i st ,  dec_ids, 
open_schema,  check _pred_schema 
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CHAPTER  12 


SYNTACTIC,  DATATYPE  AND  SCHEMA  DEFINITIONS 

|Z_datatypes  :Hodule| 

|2_scopes  : nodule] 

|Z_type_porm  :f1odule| 

|2_dec_and_inc  : Module] 

Syntactic  definitions 

Like  declarations,  syntactic  definitions  occur  at  various  points  in  the  syntax  and,  for 
the  non-generic  cases  are  very  similar  to  declarations.  The  main  difference  from  the 
type-checking  point  of  view  is  that  whereas  in  x  :  term,  term  must  have  the  type 
of  a  set  of  the  type  of  x,  in  x  a  term,  they  have  the  same  type.  Consequently, 
syntactic  definitions  are  made  to  appear  like  declarations.  The  syntax  for  the 
syntactic  definition  of  a  single  identifier  is 


syn_def_id  = 

glabal_id  <star t_i dl i st — idlist>  def  term  <syn_def-p i dl i st-ptype> ; 


and  it  is  imply  necessary  to  add  a  powerset  to  the  type  of  the  term  to  have  an 
equivalent  operation  to  declaration: 

add  nnuprspt  syn_def  £  add_powerset  >  dec_ids 

ty?,  ty!  :  Type 

ty!  =  powerset  ty? 


Datatype  definitions 


datatype_def  =  id  <dt_def — id>  becomes  branches  <unstack_i d-p i d> : 
branch  = 

id  <dt_constant-q i d> , 

id  lang  term  rang  <dt_constructor-ptype-q i d> ; 
branches  =  branch,  branch  bbar  branches; 


For  a  datatype  definition,  the  identifier  must  be  declared  immediately  because  the 
definition  is  allowed  to  be  recursive.  Datatypes  are  in  fact  allowed  to  be  mutually 
recursive,  but  in  order  to  keep  to  the  declaration  before  use  rule,  datatypes  used 
before  being  defined  in  a  datatype  definition  must  have  been  previously  introduced  as 
a  given  set.  For  this  reason,  the  merge  operation  is  used  rather  than  declare.  Apart 
from  this  case  of  introduction  as  a  given  set,  the  view  has  been  taken  that  datatype 
names  should  be  unique,  not  only  within  the  current  document  but  also  within  any 
referenced  documents,  including  the  standard  library.  This  avoids  some  problems  of 
confusing  types  and  allows  datatypes  to  be  uniquely  specified  from  their  name  and  to 
have  the  same  type  as  a  given  set. 
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dt_dec  _ 

Merge 
ALexState 
id!  :  Id 


id!  =  hd  idl ist 
Mid!  t  domtfind  SEnv ) 

v  find  SEnv  id!  =  powerset (g i ven  id!  ))  -* 
rep!  =  "Datatype  not  unique" 
merge_ids  =  -fid!  •*  powerset  (g  i  ven  id!)> 
ctuple’  =  ctuple 
idl  ist'  *  tl  idl  ist 


dt_def  a  dt_dec\(merge_ids ) 

The  datatype  constants  are  straightforward: 

dt_constant_dec  _ 

Declare 
ALexState 
id?  :  Id 


new_ids  =  <hd  idl  ist)  a.  ty  =  given  id? 
idl ist’  =  tl  idl ist 


dt_constant  a  dt_constant_dec\(new_i ds ,  ty  ) 

For  the  constructor  functions,  the  requirement  that  recursive  references  to  the 
datatype  involve  only  finite  sets  is  regarded  as  a  proof  obligation,  rather  than  a 
failure  of  type  checking. 

dt_constructor_dec _ t 

Declare 

ALex5tate 

id?  :  Id;  ty?  :  Type 


new_ids  =  <hd  idl ist) 
idl ist’  =  tl  idl ist 

ty  =  ponerset(tuple<ty?,  given  id?)) 


dt_constructor  *  Normalise  >  dt_construetor_dec\(new_i ds ,  ty  ) 

On  the  completion  of  a  datatype  declaration,  the  SID  Id  stack  must  be  reset  using  the 

unstack _ •  df unction,  but  as  the  SID  stacks  are  not  modelled  in  the  specification,  the 

corresponding  operation  is  not  specified  here. 

Schema  definitions 


For  compatibility  with  declarations  and  definitions,  the  schema  name  is  stacked  as  a 
list  of  identifiers  and  the  schema  is  declared  using  ayn_def. 
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!schema_def  = 

id  <start_i dl i st — idlist> 

schemB_def  i  n  i  t  i  on  <syn_def-p  i  dl  i  st-ptype>, 

id  <start_i dl i st — idlist>  gen_params 

scheraa_def in i t ion  <end_scope><syn_def-p i dl i st-ptype> ; 

schema_def i n i t i on  = 

< check _schema_i d-p i dl i st — idlist>  sdef  schema_term, 

< check _schema_i d-p i dl i st — i dl i st  >  schema ; 


For  a  schema  name,  the  identifier  must  be  undecorated: 


i dl i st ! »  i dl i st9 
rep!  :  seq  Char 

:  seq  Id 

schema  id.att 

t  noatt  v  schema 

id. version  y  noname  — * 

rep!  =  "Schema  name  must  be 

undecorated" 

i dl i st !  =  < i d' 

> 

where 

schema_id  s  hd 

i dl i st? 

id’  a  p  Id 

I  name  = 

schema_i d- name 

vers i on 

=  noname  a  att 

=  noatt 

synstat 

=  i dent 

.  eld 

The  syntax  for  schemas  is 


schema  = 

sb  <new_scope>  dec_l  i st  <scope_to_schema_t>/Pe — type>  esb, 
sb  <new_scope>  dec_l i st 

st  pred_l i st  <unstack_pred-ptype><scope_to_schema_type — type>  esb. 
sch  <new_scope>  dec_l i st  <scope_to_schema_type — type>  esch, 
sch  <new_scope>  dec_l i st 

cbar  pred  <unstack_pred-ptypeXscope_to_5chema_type — type>  esch; 


For  a  schema,  the  type  is  derived  from  the  scope  which  was  created  for  the  schema 
signature,  and  the  scope  discarded: 

_ _ scope_to_schema_type _ 

endjscope 
ty!  :  Type 


ty!  =  powerset(schema_type  (hd  blocks). ids) 


The  function  unstack_pred  disposes  of  the  type  produced  by  pred_list,  and  will 
be  discussed  later. 

2_syn_data_schema_def  keeps  syn_def ,  dt_def .  dt_constant, 

dt constructor  .  check_schema_i  d. 
scope_to_schema_type 
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CHAPTER  13 

OPERATOR  AND  GENERIC  SET  DEFINITIONS 

|Z_datatypes  ; Module] 
fZ_scopes  :f1odulej 
!2_type_norm  iHodule" 

Declaration  of  operator  symbols 


At  various  points  within  the  syntax  it  is  possible  to  indicate  the  syntactic  status  of 
the  identifier  being  defined  so  that  it  becomes  an  infix,  postfix  or  prefix  operator 
symbol  or  relation,  with  a  consequential  constraint  on  its  type.  The  syntactic  status  is 
dealt  with  immediately  after  encountering  the  identifier  in  the  definition  while  the 
compatibility  of  the  type  with  the  arity  of  the  symbol  is  checked  on  completion  of 
the  declaration. 


global_id  = 
i  d, 

id  underline  <global_sym-l >, 
underline  id  <global_sym-2> , 
id  underline  id  <global_sym-5>» 

lpar  underline  id  underline  rpar  <global_sym-3> , 
underline  id  underline  <global_sym-A>, 
id  underline  id  underline  <global_sym-S>, 
underline  id  underline  id  <global_sym-?> 1 


_ global_sym 

I  DLex5tate 
n7  :  1..7 


hd  idlist’  =  p  Id;  Id' 

I 8ld  =  hd  idlist 

name'  =  name  a  version'  =  version  a  att’  =  att 
synstat'  =  syn 
where 


syn 

Synstatus 

n7 

= 

1 

syn 

= 

preop 

n7 

= 

Z 

-* 

syn 

= 

postop 

n7 

= 

3 

syn 

= 

OP 

n7 

= 

A 

-* 

syn 

= 

rel 

n7 

= 

5 

— » 

syn 

= 

encopf idlist  2). name 

n7 

= 

6 

— ► 

syn 

= 

di stpreopl i dl i st  2). name 

n7 

= 

7 

-w 

syn 

= 

di  St  inopC  i  dl  i  st  2)-name 

•  0ld' 

n7  >  4  «  tl  idlist’  =  tl(tl  idlist) 
n7  S  t  »  tl  idlist'  =  tl  idlist 


Syntactic  definition  of  generic  operators 

During  a  generic  syntactic  definition,  the  syntactic  status  of  an  identifier  may  also  be 
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defined,  but  in  this  case  the  parameter  positions  are  indicated  by  the  presence  of 
generic  types.  In  this  one  pass  system,  the  syntactic  status  of  the  identifier  is 
established  at  the  definition  itself,  so  the  various  sorts  of  syntactic  definition  all 
appear  to  be  a  succession  of  up  to  three  identifiers.  The  syntax  below  provides  the 
semantic  functions  to  enable  this  to  be  sorted  out. 


syn_def_ids  = 

id  id  <prepostsymbo 1 — i d 1 i st >  def  term  <syn_def-p i dl i st~ptype> . 
id  id  id  < i nsetsymbol — idlist> 

def  term  <syn_def-p i dl i st-ptype> ; 


Prefix  and  postfix  generic  set  definitions  are  syntactically  equivalent  to  id  id  but 
may  be  distinguished  semantically  by  whether  the  identifiers  have  been  declared  and 
whether  they  are  generic  types  or  not  (one  should  be  undeclared,  one  should  have 
generic  type).  This  is  done  by  the  prspostsymbo 1  compiling  function  which  delivers 
an  identifier  list  containing  a  single  identifier  which  is  the  generic  set.  The  first  case 
is  with  the  first  parameter  the  generic  type  and  the  second  a  postfixed  generic  set. 

_ check_genpar 1  _ 

EEnv 

ALexState 
i dl i st !  :  seq  Id 


idlist(l)  €  domCfind  eEnv) 
ty  e  rng  powerset 
powerset'1  ty  e  rng  generic 
where 

ty  £  find  eEnv  (idlist(l)) 
idlist(Z)  *  domtfind  eEnv) 
idl ist (  =  <y  Id;  Id' 

|  Bid  =  i dl i st (Z  ) 

name’  =  name  a  version’  =  version 

att’  =  ett  a  synstat ’  =  postset  ( i dl i st ( 1  ) ). name 

.  eld’ 

) 

idl ist'  =  1 1 C 1 1  idl ist  ) 


In  the  second  case,  the  first  identifier  is  a  prefix  generic  set  and  the  second  the 
generic  type: 
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idlisttl)  0  domtfind  s£nv  ) 
idlist(2)  6  domtfind  8Env  ) 
ty  e  rn9  powerset 
powerset'1  ty  e  rng  generic 
where 

ty  a  find  0Env  (idlist(Z)) 
i dl i st !  =  (  p  Id;  Id’ 

I  6ld  =  i dl i st  1 1  ) 

name'  =  name  a  version’  =  version 
att*  =  att  a  synstat’  =  preset  (  i  dl  i  st  1 2  ) ).  name 
•  8  Id ' 

> 

i dl ist’  =  tlttl  idl ist  5 


For  the  error  case,  the  identifier  list  is  constructed  arbitrarily  using  the  first 
identifier. 

genpar_error  _ i 

ALexState 

idl ist!  :  seq  Id 

rep!  :  seq  Char 


i dl i st !  =  < idl i st ( 1  ) ) 

rep!  =  “Incorrect  operator  definition" 
idlist'  =  tlttl  idlist) 


prepostsymbol  a  genpar_error  •  (check_genparl  v  check_genpar2 ) 

For  infixed  operators,  a  succession  of  3  ids,  the  generic  parameters  must  be  the 
outermost  identifiers.  These  are  checked  to  be  generic  and  the  middle  identifier 
made  into  an  infixed  generic  set. 
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The  compiling  function  setop  is  simply  required  to  stack  the  name  of  the  identifier: 

rSEtop _ , 

ALexState 
ident!  !  Id 

ident!  =  hd  idlist  a  idlist’  =  tl  idlist 

_ i 

To  carry  out  the  instantiation,  a  binding  list  instantiation  is  made  up  using  the  name 
stored  with  the  syntactic  status  of  the  generic  identifier: 

set_inst  _ _ 

inst!  :  Instantiation 
ty?,  ty!  :  Type 
ident7  :  Id 
EEnv 

inst!  =  b i nd i ns_l i st< i dent  ~  ty7> 
ty!  *  find  eEnv  ident? 
where 

ident  i  u  Id 

I  name  *  preset"1  ident7. synstat 
version  =  noname 
att  *  noatt  a  synstat  =  ident 
.  eld 


and  the  compiling  functions  are  given  by 

set_instl  a  Check _type  »  set _i  net  >  inst 
set_inst2  a  setop  >  set_instl 

For  the  infixed  generic  sets,  two  sets  have  to  be  instantiated 

inset_inst  _ 

inst!  :  Instantiation 
tyl?,  tyr?»  ty!  :  Type 
ident?  :  Id 
EEnv 


inst!  =  b i nd i ng_l i stf i dl  ~  tyl'?,  id2  w  tyr7> 
ty!  =  find  8Env  Ident7 
where 

idl  £  m  Id 

I  name  =  (inset"1  i  dent?,  synstat  )  1 
version  =  noname 
att  =  noatt  a  synstat  =  ident 

.  eld 

id2  £  p  Id 

I  name  =  (inset"1  ident?. synstat  )  2 
version  =  noname 
att  =  noatt  A  synstat  =  ident 

•  Bid 


inset  £  Check_type[tyl?/ty?/  tyl i /ty ; ] 

a  Check -type[tyr?/ty9/  tyr!/ty>] 
>  inset_inst  >  inst 


2_op_def  keeps  global_sym,  prepostsymbol ,  insetsymbol. 

setop,  set_instl,  set_inst2,  inset 
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CHAPTER  14 


4 


4 


i' 


l 


PRIMITIVE  TYPES 


|2_datatypes  :t1odule| 
|2_type_un  i  fy  :I1odule] 
|Z_scopes  :Hodule| 

Explicit  constructions 


expl i c i t_constr  = 
tuple, 

set  eset  <empty_set — type>» 

explicit_set  termlistl  eset  <expl i c i t_set-ptype — type>, 
lseq  rseq  <empty_list — type>» 

lseq  termlistl  rseq  <expl i c i t_l i st-ptype — type>; 


In  the  syntax  above,  explicit_set  is  a  terminal  symbol  inserted  by  a  look-ahead 
function  in  the  lexical  analyser  to  resolve  the  problem  of  disentangling  -fa,  b,  c> 
from  {a,  b,  c  :  T...}.  The  compiling  functions  required  are  relatively  trivial;  for 
an  empty  set  the  type  required  is  powerset  of  variable: 

empty_set  _ , 

ATypeState 
ty!  :  Type 


ty!  =  powerset (var i able  n) 

tenv'  =  tenv  a  valid_names’  =  -Cn>  U  valid_names 
where 

n  :  TName  |  n  t  valid_names 


and  similarly  for  an  empty  list: 

empty_list  _ 

ATypeState 
ty!  :  Type 


ty!  =  powerset(tuple<2type,  variable  n>) 

tenv’  =  tenv  a  valid_names'  =  tn>  U  valid_names 
where 

n  :  TName  I  n  t  valid_names 

An  explicit  set  is  a  powerset  of  its  elements: 

explicit_set  _ _ 

I  ty!,  ty?  :  Type 


ty!  =  powerset  ty? 


and  similarly  for  an  explicit  list: 
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expl i c i t _ 1 ist  , 

I  ty ! »  ty?  :  Type 

ty!  =  powerset(tuple<Ztype,  ty?>) 

Both  sets  and  lists  must  be  made  up  of  elements  of  the  same  type: 


termlistl  =  *  terms  of  the  same  type  n 
term, 

term  comma  termlistla; 
terml istla  = 

term  <check_tys_same-ptype-ptype — type>, 

term  <check_tys_same-ptype-ptype — type>  comma  termlistla; 

An  arbitrary  choice  is  made  to  deliver  the  first  type  in  the  series: 

r  check _tys_same  , 

TypeCheck[tyl9/tyl>  tyZ'VtyZ J 
ty!  i  Type 

ty!  =  tyZ7 

Special  constants 

The  various  constants  appear  as  members  of  the  atomic  formulae: 


aform  = 

<nat — type>  nat , 

<chai - type>  char, 

<sconst-lv — type>  sconst , 


The  special  constants  are  the  numbers  and  strings,  distinguished  by  the  type  of  the 
lexical  value  delivered  by  the  lexical  analyser. 

sconst  _ _ _ 

I  lv?  :  LexUal;  ty!  :  Type 


lv?  e  rng  num  a  ty!  *  Ztype 
v 

lv?  e  rng  char  a  ty!  =  Char type 
v 

lv?  e  rng  string  a  ty!  =  powerset(tuple<Ztype,  Chertype)) 


The  terminal  symbols  nat  and  char  are  i  and  Char  respectively;  they  are  built  into 
the  syntax  in  this  way  in  order  to  prohibit  their  re-definition. 
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ty ! 

"""■"  . . . . . I 

•  Type 

ty!  :  Type 

ty! 

*  powerset  2t ype 

_ _ —  — - -  -  -i 

ty!  =  powerset  Chartype 

Projections 


aform  = 

i  ... 

aform  proj  id  <proj-ptype — type>. 


A  projection  may  only  be  applied  to  a  schema  type  and  must  identifiy  a  member  of 
the  schema's  signature.  In  the  error  cases  the  type  is  left  unchanged. 


proj_ok  _ 

I  ULexState 
I  ty?,  ty!  t  Type 


ty">  e  rng  scbema_type 
hd  i dli st  e  dam  idmap 
ty!  =  idmapthd  idlist) 
where 

idmap  s  schema_type'1  ty”? 
idlist’  =  t 1  idlist 


_not_schema _ 

ALexState 
ty?.  ty!  :  Type 
rep!  :  seq  Char 


ty7  *  rng  schema_type 
idlist’  «  tl  idlist 
ty)  =  ty7 

rep!  =  "Projection  may  only  be  applied  to  schemas" 


„ id_not_in_sig  _ 

ALexState 
ty?,  ty!  :  Type 
rep!  :  seq  Char 


ty7  e  rng  schema__type 

hd  idlist  4  domtschema^type'1  ty? ) 

ty!  =  ty? 

idlist'  *  tl  idl ist 

rep!  *  "Identifier  not  defined  in  schema" 
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proj  *  not_gchema  v  id_not_in_si9  v  proj_ok 
Z_pr i m i t i ves  keeps  empty_set »  empty_list>  expl icit_set» 
expl ic i t_l i st ,  eheck_tys^same. 
net.  char ,  sconst ,  proj 
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CHAPTER  15 


TUPLES,  PRODUCTS,  THETA  TERMS  AND  COMPREHENSIONS 


|Z_datatypes 

flodule] 

]Z_scopes  :  flodu  le | 

|Z_type_un  i  fy 

:  Module) 

|Z _pr  i  m  i  t  i  ves 

iflodule] 

Syntax 

tuple  = 

lpar  term  comma  terml ist2  rpar, 
theta  reference  <theta-ptype — type>: 
t*  the  reference  is  to  a  schema  » 

termlist2  =  aterms  for  a  tuple  » 
term  <f i rst_tuple-ptype — type>» 

term  <f i rst_tuple-ptype — type>  comma  terml ist2a; 
terml i st2a  = 

term  <next_tuple-ptype-ptype — type> , 

term  <next_tuple-ptype-ptype — type>  comma  terml ist2a; 


Tuples 


An  explicit  tuple  is  easily  compiled  as  it  is  simply  a  matter  of  combining  the  types 
into  a  list: 


^first^uple _ 

ty7,  ty!  :  Type 

ty!  =  tuple<ty?> 


next_tuple 

ty?,  tuple7,  ty!  :  Type 

ty!  =  tuple!  ( tuple"’tuple?  )  snoc  ty7  ) 


Theta  expressions 

A  theta  expression  forms  a  tuple,  having  a  schema  type,  from  identifiers  defined 
within  the  current  environment  and  members  of  the  schema  referenced.  Unlike  a  simple 
schema  reference  the  type  of  the  delivered  result  is  an  element,  not  a  set.  As  the 
theta  expression  only  involves  a  reference,  rather  than  an  expression  it  is  not 
necessary  to  use  type  unification. 

theta_schema _ , 

Schema_oU 
ty!  :  Type 


ty!  *  powerset*1  ty7 

■ 

For  the  error  cases,  the  type  is  passed  through  unchanged: 
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not_schema  _ 

j  t y7.  ty!  :  Type 
I  rep !  :  seq  Char 


-.Schema 
ty!  *  ty? 

rep!  =  'Schema  required  here “ 


schemajjndef i ned 
SEnv 

ty?.  ty!  :  Type 
rep !  :  seq  Char 


Schema  a  ‘,Schema_ol< 
ty!  =  ty? 

rep!  =  'Schema  identifiers  not  present  in  this  environment 


theta  fi  not_schema  v  schema_undef ined  v  theta_schema 
Products 


product  =  term  <f irst_prod-ptype — type?  prod  product  1 
<end_prod-ptype — type?; 

product  1  * 

term  <next_prod-ptype-ptype — type?/ 

term  <next_prod-ptype-ptype — type?  prod  productl; 


A  Cartesian  product  is  formed  from  sets  and  forms  a  set  of  tuples  of  the  constituent 
types.  The  compiling  functions  are  similar  to  those  for  tuples  with  the  additional 
complication  of  removing  powerset  constructors:  to  avoid  problems  with  type  variables, 
this  has  to  be  done  by  type  checking  against  a  type  consisting  of  a  powerset  of  a 
new  variable  type.  The  powerset  constructor  for  the  tuple  is  added  at  the  end  of 
the  product. 


prod _ 

TypeCheck[ty?/tyI(  ptype/tyZ] 
ty!  :  Type 


ty!  *  var iable  n 

val  id_r>ames'  =  valid_names  U  -£n> 

where 

|  n  :  TName 


_ f i rst_member  _ 

ty?.  ty!  :  Type 

ty!  =  tuple(ty7> 


I  n  *  valid_/iames 
ptype  *  powerset  ty! 


first_prod  *  prod\(ptype)  >  firstjnember 
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The  same  procedure  is  applied  to  subsequent  members  of  the  product,  with  the  result 
being  added  to  the  end  of  the  list: 

rnext_member  _ , 

prod£this_prod/ty! ] 
prod?.  ty!  :  Type 


ty!  =  tupleC (tuple-1  prod?)  snoc  this_prod) 


next_prod  S  next_member\(ptype.  this _prod) 

Finally,  the  powerset  constructor  is  added  at  the  end  of  the  product: 

_ end_prod  ( 

ty?.  ty!  :  Type 

ty!  =  powerset  ty? 


Comprehension  terms 


comprehension  = 
schema. 

set  <new_scope>  dec_list  comp_set  eset . 
lambda  <new_lambda_scope> 
dec_list  lambda_set  < lambda-ptype — type>. 
mu  <new_scope>  dec_l i st  lambda_set  <end_scope>i 

comp_set  = 

<scope_to_tuple — type>, 

cbar  pred  <unstacl<_pred-ptype><scope_to_tuple — type>. 
dot  term  <set~ptype — type>. 

cbar  pred  <unstack_pred-ptype>  dot  term  <set-ptype — type> ; 

lambda _set  = 
dot  formula. 

cbar  pred  <unstack_pred~ptype>  dot  formula; 


The  standard  set  comprehension  is  defined  to  deliver  a  set  of  tuples,  formed  either 
from  the  characteristic  tuple  of  the  declarations  in  the  comprehension  or  as  provided 
by  the  example  term.  A  new  scope  is  created  on  entry  to  the  comprehension  and 
converted  into  a  tuple  using  the  function  below. 

tuple_of_scope _ ^ 

AEnv 

ty!  :  Type 


Octuple  >  1  ty!  =  powerset ( tuple  ctuple) 

•ctuple  *  1  ty!  =  powersetihd  ctuple) 


scope_to_tuple  »  tuple_of_scope  I  end_scope 
The  set  function  is  called  when  an  example  term  is  provided  and  adds  a  powerset  to 
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its  input  type  and  ends  the  current  scope.  Consequently  it  is  a  composition  of 
previously  defined  operations: 

set  a  explicit_set  i  end_scope 

The  X  comprehension  uses  the  scope  for  the  parameter  type  and  the  example 
term  for  the  result  type: 

r  lambda 1  , 

Scope_to_tuple[typar/ty(] 
ty ! .  ty?  :  Type 


ty!  =  powerset  ( tuple  (power  set"1  typar ,  ty7>) 


lambda  fi  lambdal \( typar  ) 

2_tuples  keeps  first_tuple,  next_tuple,  theta, 
first_prod,  next _prod,  end _prod, 
scope_to_tuple .  set,  lambda 
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CHAPTER  16 


FUNCTION  APPLICATION  AND  PARTIAL  APPLICATION 


|Z_datatypes  :  Hodule! 

|Z_scopes  :f1odule! 

[2_type_un  ify  : Hodule! 

|Z_references  sflodulej 
IZ_anon_i nst  : Module 

Type  checking  for  function  application 

Most  of  the  syntax  for  function  application  is  concerned  with  indicating  the  binding 
of  the  various  forms  of  operator,  and  then,  for  the  infixed  forms,  assembling  the 
parameters  into  tuples. 


formula  = 
f  orml ; 
forml  = 

forml  op  <funop--type>  form2  < i nf i x-ptype-ptype-ptype — type>. 
form2: 

form2  = 

form2  form3  <funapp-ptype-ptype — type>. 
form3; 

form3  = 

preop  <funap — type>  form3  <fur>app-ptype-ptype — type>. 
distpreop  <funop — type> 

term  eop  form3  <d i stpreop-ptype-ptype-ptype — type>, 
powerset  form3  <powerset_fn-ptype — type>, 
formA ; 

formA  = 

formA  distinop  <funop — type> 

term  eop  < i nf i x-ptype-ptype-ptype — type>. 
formA  postop  <postapp-ptype — type>, 

aform; 


The  specification  for  the  basic  type  checking  of  function  application  is,  loosely,  that 
given  a  supposed  function,  of  type  1 1 ,  an  argument  of  type  t2,  one  creates  a  new  type 
t3  which  will  be  the  type  of  the  delivered  result.  The  type  checking  consists  in  the 
unification  of  tl  with  t2  ->  t3. 
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rfunappl  _ . 

TypeCheck(fun9/tylj  fun/ty21 
par?,  ty!  :  Type 


ty !  =  var i able  n 

valid_names’  =  valid_names  U  tn> 
where 

|  n  :  TName 


|  n  t  vslid_names 
fun  =  powerset (tuple  (par?,  ty!>) 


funapp2  S  funappl\(fun ) 

Note  that  this  is  not  a  complete  specification  for  the  compiling  function  funapp  as  it 
is  necessary  to  take  account  of  the  possibility  of  term  term  being  a  set  membership 
predicate.  This  is  dealt  with  later. 

The  function  funop  is  used  when  an  operator  symbol  has  been  recognised,  and  is 
equivalent  to  an  identifier  reference  followed  by  anonymous  instantiation. 

funop  fi  reference  t  anon_inst 

For  infixed  application  it  is  necessary  to  calculate  the  parameter  type: 

i  n  f  i  x  1  .  . . . . .  . .  . 

I  funappZ 

rhpar?,  lhpar?  :  Type 


par?  =  tuple  (lhpar?,  rhpar?) 


infix  £  inf  ixlNtpar'7  ) 

and  postfixed  application  is  a  combination  of  an  operator  symbol  and  function 
application. 

postapp  £  fun°P[fun ! /ty ! 1  >  funaP?2 

The  specification  for  distpreop  is  the  same  as  that  for  infix:  the  implementation 
differs  only  in  the  order  of  the  parameters,  which  is  determined  by  the  order  in 
which  the  types  are  stacked  which  differs  in  the  two  cases. 

The  powerset  function  is  completely  trivial: 

power  set_fn _ , 

I  ty?,  ty!  :  Type 


ty!  =  powerset  ty7 

_ i 
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Type  checking  for  set  membershi; 


h 


This  is  syntactically  the  same  as  function  application  (term  term),  but  indicates  a 
predicate  rather  than  a  term.  Type  checking  of  this  phrase  assumes  function 
application;  if  this  fails,  type  checking  for  set  membership  is  tried;  if  this  fails  the 
reply  for  function  application  is  delivered. 


.  funapp_ok 
funapp2 


rep!  =  "OK” 

-  ■ 


rsetmem _  .  .  _ 

TypeCheck[set?/tyl>  set/ty2] 
mem?*  ty!  .•  Type 


set  =  powerset  mem? 
ty!  =  predicate 
rep!  =  “OK" 


funapp  a  (funa pp2  •  (setmem\(set  ) ) )  •  funapp_ok 


Partial  application 


Partial  application  consists  of  operator  or  relation  symbols  considered  as  a  term  in 
their  own  right,  and  infixed  operators  with  one  parameter  supplied.  The  syntax  is 
fairly  complicated  to  take  into  account  the  various  forms  of  operator,  but  only  a  small 
number  of  compiling  functions  are  required. 


part i als  = 

underline  rel  underline  <partrel — type>* 

underline  op  <funop — type>  form2  <partopl-ptype-ptype — type>. 
aform  op  underline  <partop2-ptype — type>. 
underline  op  underline  <funop~~type>* 
underline  distinop  <funop — type> 

term  eop  <partopl-ptype-ptype — type>» 
aform  distinop  underline  eop  <partop2~ptype — type>. 
underline  distinop  underline  eop  <funop — type>. 
distpreop  underline  eop  underline  <funop — type>< 
distpreop  <funop — type> 

term  eop  underline  <partopl-ptype-ptype — type>» 
distpreop  underline  eop  <funop — type> 
for m3  <partopl-ptype-ptype — type>* 
encop  underline  eop  <funop — type>* 
preop  underline  <funop — type>* 
underline  postop  <funop — type>; 


If  no  parameters  are  supplied  for  operator  symbols  then  the  type  of  the  symbol  is  all 
that  is  required;  however,  for  a  relation  it  is  necessary  to  remove  the  predicate 
result  from  the  type.  This  can  be  done  directly  as  it  is  derived  from  the  identifier 
look-up. 

_reltype _ _ 

ty?*  ty!  :  Type 


ty!  =  powersetlhd  tys ) 
where 

tys  a  tuple'Upowerset*1  ty?) 
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partrel  a  (reference  >  reltype  )  J  snon_inst 

For  partial  application  proper,  a  variable  type  is  supplied  for  the  missing  parameter, 
and  then  the  function  infix  is  used  to  calculate  what  the  result  type  would  be.  This 
then  gives  the  type  for  the  partial  application  as  a  function  from  the  variable  type 
to  the  result  type.  When  the  left  hand  parameter  is  supplied  this  is 

rpartop _ , 

'n^'x[tyres/ty ! 1 
ty!  :  Type 


lhpar?  *  variable  n 
valid_names'  =  valid_names  U  <r>> 
where 

I  n  :  TName 


|  n  t  valid_names 

ty!  *  powersetttupledhpar?#  tyres)) 


partopl  £  partop\(tyres.  lhpar?  ) 

The  right  hand  parameter  case  is  a  simple  variation  on  this. 


partopZ  S  funoP[fun!/ty, j  » 

partQp[lhpar?/rhpar?,  rhpar?/lhpar?  1 V(  t>'res  ’  rhpar?) 
Z_funapps  keeps  funop.  infix,  postapp.  powerset.  funapp, 
partrel.  partopl.  partop2 
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CHAPTER  17 


RELATIONS  AND  PREDICATES 


|Z_datatypes  !Hodule| 
|Z_scopes  if1odule| 
|2_type_un  i  fy  rflodulej 
|Z_type_norm  :Hodule| 
|2_funapps  :Hodulej 

Relations 


Relations  involve  a  straightforward  variation  on  type  checking  for  function 
application.  The  syntax  is 


rel_exp  = 

term  member  term  <member-ptype-ptype — type>. 

term  equals  equals_tail  <to_pred-ptype — type>. 

term  rel  <funop — type>  rel_tail  <to_pred-ptype — type>< 

apred; 

equals_tail  = 

term  <equals-ptype-ptype — type>  tail; 

tail  = 

S, 

rel  <funop — type>  rel_tail# 
equals  equals_tail; 

rel_tail  = 

term  <rel-ptype-ptype-ptype — type>  tail; 


The  specification  for  set  membership  is: 

_ member  1 _ _  member  a  member  1\( set  ) 

TypeCheckCset7/t),lf  set/ty2] 
men'’,  ty!  ;  Type 


set  =  powerset  mem7 
ty!  =  predicate 


while  that  for  equality  allows  for  the  continued  form  and  delivers  the  type  of  the 
right  hand  operand: 

r  equals _ , 

TypeCheck[tyl7/tyl#  ty27/tyZ] 
ty!  ;  Type 


ty!  =  tyZ? 


A  relation  is  similar  to  an  infixed  function  application,  and  like  equality  delivers  the 
type  of  the  right  hand  operand  for  the  continued  form. 
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_ fell  (  rel  *  rell  Vpred) 

inf ixCpred/ty! I 
ty!  :  Type 

ty!  =  rhpar? 

On  completion  of  a  relation  or  equality,  a  predicate  is  delivered: 

to_pred _ , 

ty?»  ty!  !  Type 

ty!  =  predicate 

Note  that  with  this  specification,  the  terms  need  not  be  completely  defined,  although 
the  predicate  result  is.  This  allows  an  expression  such  as  &  e  dom  <  >  to  type  check 
correctly,  even  though  it  is  still  generic.  This  is  allowed  because  the  actual  type  may 
only  be  fixed  as  a  result  of  the  type  checking  of  a  complicated  predicate  involving 
several  relations. 


Predicates 

In  order  to  resolve  various  syntactic  ambiguities,  both  predicates  and  terms  are 
produced  as  a  result  of  the  expansion  of  the  syntax  rule  for  pred.  In  effect  a 
predicate  is  formed  by  combining  terms  using  the  loosely  binding  operators  of  the 
predicate  calculus.  Once  it  has  been  established  that  a  term  is  destined  to  be  a 
predicate  there  are  three  allowable  possibilities  for  the  type:  it  may  be  a  predicate, 
undefined  or  a  schema.  The  last  case  breaks  down  into  two  according  to  whether  the 
predicate  is  a  schema  inclusion  in  disguise  and  destined  for  the  hypothesis  part  of  a 
theorem  or  a  predicate  at  any  other  position:  in  the  former  case  the  signature  is 
t  merged  into  the  current  scope,  in  the  latter  it  must  be  present  within  the  current 

scope.  The  latter  case  is  detected  syntactically  and  checked  using  the  functions 
check_pred  and  unstack_pred  which  occur  throughout  the  syntax  in  situations  such 
as  the  following: _ 


log_exp  = 
log_expl , 

log_exp  <unstack_pred-ptype>  iff  log_expl 
<check_predl-ptype — type>; 


check_predn  _ 

ty?,  ty!  :  Type 
rep!  ••  seq  Char 


-•(ty?  =  predicate  v  ty?  =  type_undef ined  v  Schema) 
«■*  rep!  *  "Predicate  required  here" 


__  schema_wrong _ 

HEnv 

ty?>  ty!  s  Type 
rep)  i  seq  Char 


Schema  a  ■'Schema_ok 
ty!  =  predicate 

rep!  =  "Schema  identifiers  not  present  in  this  environment" 


checkered  a  Normalise  >  check _predn  v  schema_wron9  v  Schema_ok 

The  other  function,  unst  ack_pred,  is  not  required  to  deliver  a  type: 

unstack_pred  a  check_pred\(ty !  ) 

2_preds  keeps  member,  equals,  rel,  to_pred, 
checkered,  unstack_pred 
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CHAPTER  18 


SCHEMA  EXPRESSIONS 


|2_datatypes  iModule| 
|Z_scopes  i  Module} 

Quantified  schema  terms 


quant_sexp  =  squant  <new_scope>  dec_list 

dot  schema_term  <subtract_scope-ptype — type>; 

i _ 

A  new  scope  is  formed  for  the  quantified  identifiers,  which  must  all  be  present  and 
with  the  correct  type  within  the  schema  type.  The  new  schema  type  is  the  difference 
between  the  two,  assuming  this  is  not  empty. 

subtract _scopal  _ , 

SEnv 

ty?.  ty!  :  Type 
rep!  !  seq  Char 


ty!  =  powerset(schema_type  ids’  ) 
dom  good_ids  =  dam  ids  ^ 

rep!  =  "fill  identifiers  quantified" 

-■(dom  good_ids  C  dom  ids)  — * 

rep!  =  "Identifier  to  be  quantified  not  present" 

"in  schema" 
bad_ids  *  {>  — * 

rep!  =  "Quantified  identifier  has  inconsistent  type" 

where 

ids  s  schema_t  ypeM(  power  set'1  ty?  ) 
quants  s  (hd  blocks). ids 
bad_ids  s  quants  inconsistent  ids 
good_ids  S  bad_ids  4  quants 
ids’  S  dom  good_ids  4  ids 


subtract_scope  &  subtract_scopel  I  end_scope 
Logical  schema  expressions 

The  infixed  operators  all  have  a  similar  form,  exemplified  by: _ 

log_sexp  = 
lo9_sexpl, 

lo9_sexp  riff  log_sexpl  <stype2-ptype-ptype — type>; 
The  two  schemas  may  be  combined  if  their  signatures  are  consistent. 
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stypeZ  _ 

tyl?,  tyZ?»  ty!  :  Type 
rep!  :  seq  Cher 


ty!  =  power set (schema_type( idsl  u  idsZ'  )) 
bad_ids  *  O  — »  rep!  =  “Schema  terms  inconsistent” 
where 

idsl  &  schema_type*'(powersef1  tyl9) 
idsZ  &  schema_type*'(powerset"1  ty29  ) 
bad_ids  &  idsl  inconsistent  idsZ 
i dcZ ’  a  bad  ids  <  i dsZ 


The  special  purpose  schema  expressions 


spec_sexp  = 

spec_sexp  2hide  lpar  i d _ 1 i st  rpar  <h i de i ds-p i dl i st-ptype — type). 

spec_sexp  zhide  reference  <h i deref-ptype-ptype — type), 
spec^sexp  zcmp  specjsexpl  <scompose-ptype-ptype — type), 
spec_sexp  zpipe  spec_sexpl  <pipe-ptype-ptype — type), 
spec_sexp  zovr  spec_sexpl  <so verr i de-ptype-ptype — type), 
spec_sexpl ; 


For  hiding  it  is  simply  necessary  to  check  that  the  identifiers  are  present  in 
the  schema  type,  and  then  remove  them. 

h i de i ds  _ _ 

|  idlist9  :  seq  Id:  ty9.  ty!  :  Type 
I  rep!  :  seq  Char 


rna  idlist?  =  dom  ids  — * 

rep!  =  "All  identifiers  hidden” 

*»(rng  idlist9  c  dom  ids)  —* 

rep!  =  “Identifier  to  be  hidden  not  present  in  schema” 
ty!  =  powerset (schema_type  ids’  ) 
where 

ids  &  schema_type'1(powerset‘I  ty?) 
ids'  S  rng  idlist?  <  ids 


For  hiding  with  a  schema  it  is  necessary  to  check  that  the  name  is  indeed  that  of  a 
schema  and  that  it  is  compatible  with  the  schema  to  be  hidden. 
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hi deref _ok  _ 

tyref?.  tyschema?.  ty!  :  Type 
rep!  :  seq  Char 


Schema[tyref?/ty?] 

ty!  =  power set (schema_type  ids’  ) 

bad_ids  *  O  ^  rep!  =  "Schemas  inconsistent" 

ids'  =  O  -* 

rep!  =  "fill  identifiers  hidden" 

->(300d_ids  C  i  ds  )  — » 

rep!  =  "Identifier  to  be  hidden  not  present  in  schema" 

where 

idsref  a  schema^ype'U powerset"1  tyref?) 
ids  a  schema _type‘l(powerset''  tyschema?) 
bad_ids  a  idsref  inconsistent  ids 
good_ids  a  bad_ids  4  idsref 
ids’  a  ids  \  good_ids 

_ h i deref _wrong  L 

tyref7.  tyschema?.  ty!  :  Type 
I  rep!  :  seq  Char 


■’Schema  [  tyref 7/ty?  ]  -* 

rep!  =  "Only  schemas  may  be  used  for  hiding" 
ty!  =  tyschema7 


hi deref  a  hi  deref  _ok  v  h i deref _wrong 

For  the  other  schema  operations,  a  few  extra  functions  on  sets  of  identifiers  are 
needed.  First  of  all,  i  ds_w  i  th_decor  delivers  that  part  of  a  look-up  function  where 
the  identifiers  have  a  given  decoration. 

i ds_w i th_decor  a 
X  decor  :  Att 
•  X  ids  :  Id Type 

•  -C  ident  :  dom  ids  I  i dent. att  =  decor>  0  ids 

Next,  i  ds_w  i  th_basename  delivers  that  part  of  a  look-up  function  such  that  the 
identifiers  have  no  attribute,  have  the  same  base  name  and  version  in  the  decorated 
function  and  deliver  the  same  type. 

i ds_w i th_basename  a 

X  ids.  dec  ids  :  Id  ■*  Type 
•  { i dent  :  dom  ids 
I  ident.att  =  noatt 

a  (3  ident’  :  dom  dec  ids 

•  ident’. name  =  ident. name 
a  ident’ .version  =  i dent . vers i on 
a  dec i ds  ident’  =  ids  ident) 

•  ident  »  ids  ident 

} 

For  schema  composition,  find  the  set  of  identifiers  present  in  both  schemas  in  primed 
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and  unprimed  forms  and  take  the  intersection:  this  should  be  non-empty  for  schemas  to 
be  composed.  The  resulting  type  is  simply  that  of  the  merged  schemas. 

scompose  -  -  — 

1  tyl?»  ty2?,  ty!  :  Type 
rep!  :  seq  Char 


ty!  =  power set (schema_type  (ids2  u  9ood_ids)) 
undashed_i dsl  fl  undashed_i ds2  =  O  — + 
rep!  =  "Schemas  cannot  be  composed" 
bad_ids  *  <y  rep!  =  "Schemas  inconsistent" 
where 

idsl  £  schema_type‘,(powerset"1  tyl?) 
ids2  s  schema_type‘ilpowerset'1  ty2?  ) 
undashed_i dsl  £  i ds_w i th_basename( i dsl , 

( i ds_w i th_decor  (dashes  11)  idsl) 

undashed_ids2  £  i ds_wi th_basename( i dsZ , 

( i ds_w i th_decor  (dashes  1))  ids2) 

bad_ids  £  idsl  inconsistent  ids2 
good_ids  £  bad_ids  4  idsl 


For  piping  it  is  necessary  to  find  identifiers  in  one  schema  which  have  the  same  base 
name  and  version  as  those  in  another  schema: 

same_base  £ 

X  idsl,  ids2  :  Id-«Type 
«  {ident  t  dom  idsl 
I  3  ident'  :  dom  ids2 

•  ident '.name  =  ident. name 
a  ident '. version  =  i dent . vers i on 
a  idsl  ident  =  ids2  ident’ 

•  ident  idsl  ident 

> 

j-Pipe - - 

I  tyl?,  tyZ?,  ty!  :  Type 

I  rep!  t  seq  Char 


ty!  =  powerset(schema_type  (idsZ’  U  90od_ids)) 
bad_ids  *  •£>  — *  rep!  =  "Schemas  inconsistent” 

piped.outputs  *  O  — *  rep!  =  "Schemas  cannot  be  piped” 
where 

idsl  £  schema  ..type'Mpowerset'1  tyl?) 
ids2  £  schema_type''(powerset'1  ty2?  ) 
outputs  £  ids_with_decor  bang  idsl 
inputs  £  ids_with_decor  query  idsZ 
piped_outputs  £  same_base ( outputs ,  inputs) 
piped_inputs  £  same_base( inputs,  outputs) 
idsl*  £  idsl  \  p i ped_outputs 
idsZ’  £  ids2  \  piped_inputs 
bad_ids  £  idsl*  inconsistent  ids2' 
good_ids  £  bad.ids  4  idsl' 
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The  override  function  is  equivalent  to  a  logical  operation  as  far  as  type  checking  is 
concerned: 

saverr i de  a  stypeZ 

The  pr*  condition  is  simply  another  variation  on  hiding: 


spec_$expl  = 
spec_sexp2. 

pre  spec_sexp2  <pre-ptype — type>; 


_pre _ 

ty9.  ty!  :  Type 
rep!  :  seq  Char 


ty!  =  power set (schema_type  (ids  \  preids)) 
pre ids  =  O  — * 

rep!  =  "Schema  not  suitable  for  pre-condition" 

where 

ids  e  schema_type'l(powerset_1  ty?  ) 
afterids  s  i ds_w i th_decor  (dashes  1)  ids 
preids  s  afterids  U  i ds_w i th_decor  bans  ids 


Finally,  all  the  above  operations  presuppose  an  input  type  made  up  from  a  schema; 
this  is  checked  at  schema  reference: 


spec_sexp2  = 

lpar  schema_term  rpar . 
lpar  schema_term  rpar  rename . 
reference  < check _schema-ptype — type>. 
schema  J 


_ check _schema _ 

ty?»  ty!  :  Type 
rep!  :  seq  Char 


->Schema  — * 

ty!  =  powerset  (schema_type  -Cident  >»  type_undef  i  ned>  ) 

rep!  =  "Not  a  schema  type" 
where 

ident  s  u  Id 

I  name  =  noname  a  version  =  noname 
a  att  =  noatt 

.  eld 

Schema  ty!  =  ty? 


Z_schema_ops  keeps  subtract _scope .  stype2.  hideids.  hideref. 

scompose>  pipe,  soverride.  pre.  check_schema 
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APPENDIX 
THE  2  SYNTAX 


BASICS 
i  d 

document 

decor 


a  as  provided  by  lexical  analysis,  including 
decorat i on# 

a  a  specification  module  a 
a?, ! , ’  or  decor  a 


a  General  brackets  and  separators  a 


endz 

nl 

sem  i 
lpar 
rpar 
comma 
lsqb 
i  lsqb 
rsqb 
s  i 
e  i 

keep 

finish 


a  end  of  Z  picture** 
a  hard  new  linea 
a;a 
a(a 
a  )a 

a.  or  commaa 
al  or  lsqba 

a  [  in  a  version  =  i nstant i at i ona 
a]  or  rsqba 
a  start  indentationa 
a  end  indentationa 
a  export  indicator  a 
a  end  of  f i lea 


a  Declarations  and  definitions  a 


colon 

cbar 

def 

sdef 

becomes 

bbar 

lang 

rang 

sr 

er 

9G 


a:  or  colona 
«|  constraint  bara 

a»  or  def  syntactic  equivalence  for  termsa 

or  sdef  syntactic  equivalence  for  schema  termsa 
a  for  datatype  definitions" 

« I  (branch  separator)" 

a«  (left  angled  bracket  for  disjoint  union  )a 
«»  (right  "  "  "  "  )a 

a  start  vertical  rule" 
a  end  vertical  rule" 
a  unique  (generic)  definition  a 


a  Identifiers  a 


dir 

for 

under  1 i ne 
i  nset 
preset 
postset 
op 

encop 

d i st i nop 

d i stpr eop 

eop 

preop 

postop 

sconst 

a  Theorems  a 

turnst i le 

th 

eth 


a$a 

a/  (renam i ng  )a 

a_  or  underline  (place  holder  for  renaming)" 
a  infixed  generic  sets  a 
a  prefixed  generic  sets  a 
a  postfixed  generic  sets  a 
a  infix  operator" 
a  lhs  of  enclosed  operator" 
a  lhs  of  distributed  infix  operator" 
a  lhs  of  distributed  prefix  operator" 
a  delimiter  of  two  part  operators" 
a  prefix  operator" 
a  postfix  operator" 
a  numbers  and  such  a 


a  h  (theorem  )a 
a  start  theorem" 
a  end  theorem" 


a  Predicate  Natation  a 
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all 

bWb 

ex  i 

*3  or  ex i s 

ex  i  1 

B  unique  3» 

Hherel 

B  artificial  where  markers** 

where2 

B  8 

endwhere 

B  B 

dot 

B.  (such  that  )b 

equals 

B=B 

member 

BeB 

rel 

b  relational  operators 

iff 

B*tt 

i mpl i es 

B-B 

and 

bab 

or 

By/B 

not 

B-'B 

a  Term  notat i on  - 

for  sets  and  objects  b 

set 

B{  or  setbraB 

eset 

B>B 

expl  i  c  i  t. 

_set 

B  used  to  one-track  explicit  set: 

comprehens i ons« 

lambda 

b\b 

mu 

BpB 

lseq 

B  (  B 

rseq 

B  )B 

pro  j 

b.  (project  i  on  )a 

theta 

B0  tuple  constructors 

prod 

B«  cartesian  products 

power set 

sP  or  powersets 

nat 

b2b 

char 

b  Chars 

a  Schema 

notat ion 

B 

rex  i 

b3b 

rail 

aba 

Ziff 

b+b 

z i mpl i es 

B-B 

zand 

Ba« 

zor 

ByS 

znot 

B->B 

zh  i  de 

b\b 

pre 

b  pres 

zcmp 

BJ  (bold  ;)  schema  composition  s 

zp  i  pe 

s>  piping  operator  b 

zovr 

sa  (bold  •)  schema  over-ride  » 

sch 

si  (start  schema  bracket  )s 

esch 

si  (end  schema  bracket  )s 

sb 

B  start  schema  box  (after  name  )s 

st 

b  middle  line  of  schema  boxs 

esb 

B  end  schema  boxs 

RULES 

z  text  = 

finish  <return- 

-1>. 

z_phrase  finish  <return-l>. 

z_phrase  z_sep 

z_text ; 

z_sep  = 

1  i st_sep> 

endz; 

1 f  st_^ep  = 
semi  p 
nl ; 
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z_phrase  =  <store_mon-mon>  zphrasel; 

zphrasel  = 

gi ven_set_def  . 
def i n i t i on . 
constraint . 
theorem , 
import . 
export ; 

a  Given  Set  Declaration  a 

g i ven_set_def  =  lsqb  given_ids  rsqb; 

given_ids  =  id  <g i ven_set_def >  given_idsl; 

given_idsl  =  $.  comma  given_ids; 

a  Def i n i t i on  a 

def i n i t i on  = 

ax i omat i c_def  . 
syntact i c_def  . 
datatype_def » 
schema_def ; 

a  Global  Constraint  a 

constraint  =  pred; 

a  Theorems  a 

theorem  = 

turnstile  pred  <unstack_pred-ptype> > 

th  thl  turnstile  pred_list  <unstack_pred-ptype><end_scope>  eth 
adon’t  understand  sb  and  eb  at  this  point  in  Oxford  syntax  a 
thl  = 

<new_scope> . 
gen_params . 

<new_scope>  hyps. 
gen_params  hyps; 

a  a  scope  for  the  declarations  in  the  theorem  is  always  created, 
even  if  there  aren’t  any.  If  there  are  any  generic  parameters, 
the  scope  created  far  that  is  used,  otherwise  one  is  explicitly 
created, 
a 

hyps  = 
hyp. 

hyp  list_sep  hyps; 

a  N8  schema_term  omitted  because  of  ambiguities  with  schema 
reference  in  pred  in  hyp  below 

a 

hyp  = 

pred  <check _pred_schema-ptype>. 
dec . 

dec  cbar  pred  <unstack _pred_ptype>; 
a  pred  on  its  own  includes  schema_reference  « 
a  Import  a 
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import  =  document  <newdoc — docmap>  importl  <adddoc-pdocmap> : 


importl  = 

S, 

decor  <decdoc-pdocmap — docmap>. 
instantiation  < instdoc-p i nst-pdocmap — docmap> . 
decor  <decdoc-pdocmap — docmap> 
i nstant i at i on  < instdoc-p i nst-pdocmap — docmap> ; 

«  Export  * 

export  =  id  <keep>  keep  idslist  <return-2>; 

ids  =  id,  inset,  preset,  postset.  op.  rel.  encop  eop>  distinop  eop. 
distpreop  eop,  preop.  postop; 

idslist  =  ids  <keep_id>  idslistl; 

idslistl  =  S,  comma  idslist; 


u  identifiers,  names  and  references  n 
reference  = 

id  <reference — type>  ref2. 

id  dir  <check_no_att>  id  <doc_reference — type>  ref 2: 
ref2  = 

<anon_i nst-ptype — type> . 

instant  i at  ion  <  i d_mst-ptype-p  i  nst — type>; 
instantiation  =  i lsqb  inst_list  rsqb; 

inst_list  =  i nst_term_l i st .  b i nd i ng_l i st .  rename_list; 
ttgathered  together  to  resolve  various  one-track  problems** 

i nst_term_l i st  = 

term  <tmll-ptype — inst>. 

term  <tmll-ptype — inst>  comma  i nst_terml i st 1 ; 

inst_terml istl  = 

term  <tml2-ptype-pinst — inst> 
i nst_terml i st2 ; 

inst_terml ist2  =  $.  comma  inst_terml istl; 
binding_list  =  bll.  bll  comma  b i nd i ng_l i st 1 ; 
bll  = 

id  equals  <bll — id>  term  <bl2-p i d-ptype — inst>; 

binding_l istl  = 

bl2.  bl2  comma  b i nd i ng_l ist 1 ; 

bl2  = 

id  equals  <b 1 1 — id> 

term  <bl3-pid-ptype-pinst — inst>; 

rename_l i st  * 

id  for  id  <rnll — inst>, 

id  for  id  <rnll — inst>  comma  rename_l i st 1 ; 
rename_listl  «= 

id  for  id  <rnlZ-pinst — inst>  rename_l i stZ; 
rename_listZ  =  $,  comma  rename_l i st 1 ; 
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«  Axiomatic  definition  « 

ax i omat i c_def  = 

1 iberal_def » 
un i que_def  > 

9ener i c_def ; 

liberal_def  = 
global_dec. 

9lobal_dec  cbar  pred  <unstack_pred-ptype> , 
s r  def  _body  er ; 

def  _body  « 

9lobal_dec_l i st » 

9lobal_dec_l ist  st  pred_list  <unstack_pred~ptype> ; 
unique_def  =  ge  def_body  er  ; 
generic_def  = 

global_id  <start_i dl i st — idlist>  gen_params  <new_scope> 
colon  term  <dec_ids-pidl ist-ptype> 
char  pred  <unstack_pred-ptype><end_3en_def > . 
ge  gen_params  <new_scope>  def_body  er  <end  gen  def>; 

gen_params  =  lsqb  <new_scope>  given_ids  rsqb; 

global_dec_l ist  = 

9lobal_dec. 

global_dec  list_sep  9lobal_dec_l i st ; 
global_dec  = 

global_id_l ist  colon  term  <dec_ids~pidl ist-ptype>; 
global_id_l ist  = 

global_i d  <start_i dl i st — i dl i St > , 

global_id  <start_i dl i st — i dl i st >  comma  global_i d_l i st 1 ; 

global_id_l istl  = 

$, 

global_id  <stack_i dl i st-p i dl i st — i dl i st > » 

global_id  <stack_i dl i st-pi dl i st — i dl i st >  comma  global_i d_l i st 1 


9lobal_id  = 
i  d  • 

id  underline  <9lobal_sym-l>f 

underline  id  <global_sym-ZX 

id  underline  id  <global_sym-5> , 

lpar  underline  id  underline  rpar  <global__sym-3X 

underline  id  underline  <global_sym-4> / 

id  underline  id  underline  <global_sym-6>» 

underline  id  underline  id  <global_sym-7> ; 

•*  Syntactic  definition  n 

syntact i c_def  = 
syn_def_id, 

global_id  <start_i  dl  i  st — i  dl  i st  >  9en _params  <nei-i_scope> 
def  term  <syn_def-p i dl i st-ptype>  <end_9en_def > » 

9e  gen_parems  <new_scope>  syn_def_list  er  <end_aen_def > ; 

syn_def_id  = 

9lobal_id  <start_idl ist — i dl i st >  def  term  <syn_def-p i dl i st-ptype> 

syn_def_list  = 
syn_def  > 
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syn_def  list_sep  syn_def_l i st ; 

syn_def  = 

syn_def_id> 
syn_def_i  ds; 

syn_def_ids  = 

id  id  <prepostsymbol — idlist>  def  term  <syn_def-p>dl ist-ptype> , 
id  id  id  <insetsymbol — idlist> 

def  term  <syn_def-pidl ist-ptype>; 

a  various  sorts  of  pre  and  post  generic  set  definition,  depending 
on  whether  the  ids  occur  in  the  generic  parameters  or  not  a 

a  Data  type  definition  a 

datatype_def  =  id  <dt_def — id>  becomes  branches  <unstack_id-pid>; 
branch  = 

id  <dt_constant-qid>, 

id  <dt_const_id — id>  lang  term  rang  <dt_constructor-ptype~p i d-q i d> 
branches  =  branch,  branch  bbar  branches; 
a  Schema  definition  a 
schema_def  = 

id  <start_i dl i st — idlist> 

schema_def i n i t i an  <syn_def-p i dl i st-pt ype>, 

id  <start_i dl  i st — i dl  i st >  gen  jjarams 

schema_def  i  n  i  t  i  on  <end.jscope><syn_def-p  i dl  i  st-ptype> ; 

schema_def i n i t i on  = 

<check_id_schema-pidl ist — i dl i st >  sdef  schema_term, 

<check_i d_schema-p i dl i st — i dl i st  >  schema ; 

«  only  boxed  forms  should  really  be  allowed,  but  this  is  not  checkeds 

a  Schemas  a 
schema  = 

sb  <new_scope>  dec_list  <scope_tc_schema_type — type>  esb, 
sb  <new_scope>  dec_list 

st  pred_list  <unstack_pred-ptype><scope_to_schema_type — type>  esb, 
sch  <new_scope>  dec_list  <scope_to_schema_type — type>  esch, 
sch  <new_scope>  dec_list 

cbar  pred  <unstack_pred-ptype><scope_to_schema_tyPe — type>  esch; 

a  Lists  of  predicates  and  declarations  a 

pred_list  = 
pred. 

pred  <unstack_pred-ptype>  iist_sep  pred_list; 

dec_l  i  st  = 
dec, 

dec  listjsep  dec_list, 
inclus i on . 

inclusion  list_sep  dec_list; 

dec  =  i d _ 1 i st  colon  term  <dec_ids-pidl ist-ptype>; 

i  d_l  i  st  = 

id  <start_idl  ist — idlistX 
id  <start_idlist — idlist)  comma  id?,  ist  1; 
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idlistl  = 

id  < stack  _idl ist-pidl ist — idl ist), 
id  <stack_idl ist-pidl ist — idlist)  comma  idlistl; 

inclusion  =  reference  <open_schema-ptype>; 

«  and  check  reference  is  to  a  schema_term  a 

a  Explicit  construction  terms  a 

expl icit_constr  = 
tuple/ 

explicit_set  eset  <empty_set — type), 

explicit_set  termlistl  eset  <explicit_set-ptype — type), 
lseq  rseq  <empty_list — type), 

lseq  termlistl  rseq  <expl i ci t_l ist-ptype — type>; 

a  explicit_set  above  is  a  pseudo  terminal  symbol  inserted  by  a 
look-ahead  function  to  resolve  the  problem  of  disentangling  fa.  b.  c> 
from  <3/  b,  c:  T>.  The  look-ahead  function  looks  ahead  while 
encountering  id  comma:  if  terminated  by  anything  other  than  colon,  the 
explicit_set  symbol  is  delivered  instead  of  set.  a 

termlistl  =  a  terms  of  the  same  type  a 
term, 

term  comma  termlistla; 
terml i st la  = 

term  <check_tys_same-ptype-ptype — type> , 

term  <check_tys_same-ptype-ptype — type>  comma  termlistla; 


tuple  = 

lpar  term  <f i rst_tuple-ptype — type>  comma  terml istZ  rpar, 

theta  reference  <theta-ptype — type>; 
a  the  reference  is  to  a  schema  a 

terml istZ  =  aterms  for  a  tuple  a 

term  <next_tuple-ptype-ptype — type>  terml istZa; 

termlistZa  = 

S. 

comma  terml istZ; 
a  Closed  terms  a 
aform  = 

<nat — type>  nat , 

<chai - type>  char, 

<sconst-lv — type)  sconst , 
reference, 

aform  proj  id  <proj-ptype — type), 
lpar  product  rpar , 
expl icitjconstr , 

set  <new_scope>  dec_list  comp_set  eset, 
lpar  partials  rpar, 

encop  term  eop  <funapp-ptype-ptype — type), 

wherel  <new_scope>  ax_dec_list  <unstack_pred-ptype> 

whereZ  pred_list  <end_scope)<check _pred-ptype — type)  endwhere, 

wherel  <new_scope>  syn_def_list 

whereZ  pred_list  <end_scope><check _pred-ptype — type)  endwhere, 
lpar  pred  rpar; 

a  allows  bracketted  predicates. . .a 
product  = 

term  <f i rst_prod-ptype — type)  prod 
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productl  <end_prod-ptype — type); 
product  1  = 

term  <next _pr od-pt ype-pt ype — type ) . 

term  <next_prod-ptype-ptype — type>  prod  productl; 

comp_set  = 

<scope_to_tuple — type> , 

cbar  pred  <unstack_pred-ptype)<scope_to_tuple — type), 
dot  term  <set-ptype — type> , 

cbar  pred  <unstack_pred-ptype>  dot  term  <set-ptype — type); 

ax_dec_list  = 

dec_list  cbar  pred/ 
sr  dec_list  st  pred_list  er ; 

**  sr  end  er  because  I  like  it  that  way-.-» 

parti  els  = 

underline  rel  underline  <partrel — type), 

underline  op  <funop — type>  form2  <partopl-ptype-ptype — type), 
aform  op  underline  <par top2-ptype — type), 
underline  op  underline  <funop — type), 
underline  distinop  <funop — type> 

term  eop  <partopl-ptype-ptype — type), 
eform  distinop  underline  eop  <partop2-ptype — type), 
underline  distinop  underline  eop  <funop — type>» 
distpreop  underline  eop  underline  <funop — type), 
distpreop  <funop — type> 

term  eop  underline  <partopl-ptype-ptype — type), 
distpreop  underline  eop  <funop — type> 
form3  <partopl-ptype-ptype — type) > 
encop  underline  eop  <funop — type), 
preop  underline  <funop — type), 
underline  postop  <funop — type); 

•*  Formulae  a 

formula  = 

forml  inset  <setop — id>  formula  < inset-pi d-ptype-ptype — type>» 
forml; 

forml  = 

forml  op  <funop — type)  form2  < inf i x-ptype-ptype-ptype — type)* 
form2; 

form2  = 

formZ  form3  <funapp-ptype-ptype — type)* 
form3; 

form3  = 

preop  <funop — type)  form3  <funapp-ptype-ptype — type), 
preset  <setop — id)  form3  <set_instl-pid-ptype — type), 
distpreop  <funop — type) 

term  eop  form3  <di stpreop-ptype-ptype-ptype — type), 
powerset  form3  <powerset-ptype — type). 
form4; 

form4  = 

form4  distinop  <funop — type) 

term  eop  < inf i x-ptype-ptype-ptype — type), 
form4  postop  <postapp-ptype — type) . 
form4  postset  <set_inst2-ptype — type), 
eform; 

ft  Comprehension  terms  n 
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comprehension  = 

lambda  <new_lambda_scope>  dec_list  lambda_set  < lambda-ptype — type), 
mu  <new_scope>  dec_l i st  lambda_set  <end_scope>; 

lambda_set  = 
dot  term, 

cbar  pred  <unstack_pred-ptype>  dot  term; 

»  Terms  a 

term  =  comprehension/ 
formula; 

•<  Atomic  predicates  # 
apred  = 

s i  pred_l i st  e  i » 
term; 

»  term  includes  term  term  tset  membership),  schema  reference  and 
bracketted  predicate 
a 

a  Relations  a 
rel_exp  = 

term  member  term  <member-ptype-ptype — type). 

term  equals  equals_tail  <to_pred-ptype — type>. 

term  rel  <funop — type>  rel_tail  <to_pred-ptype — type>. 

apred; 

equals_tail  = 

term  <equals-ptype-ptype — type>  tail; 

tail  = 

$. 

rel  <funop — type>  rel_tail. 
equals  equals_tail; 

rel_tail  = 

term  <rel-ptype-ptype-ptype — type>  tail; 


a  Logical  expressions  a 

log_exp  = 
log  _expl . 

log_exp  <unstack _pred-ptype>  iff  log_expl 
< check _pred-p type — type>; 

log_expl  = 
log_exp2. 

log_expl  <unstack_pred-ptype>  implies  log_exp2 
<check_pred-ptype — type>; 

log_exp2  = 
log_exp3. 

log_exp2  <unstack_pred-ptype>  or  log_exp3 
<check_pred-ptype — type>; 

log_exp3  = 
log_exp5. 

log_exp3  <unstack_pred-ptype>  and  log_exp*t 
<check_pred-ptype — type) ; 

lo9_exp4  = 
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rel_exp, 

not  log_expf  <check_pred-ptype — t ypeX 
8  Quantified  expressions  8 
quant_exp  = 

quant  <new_scope>  dec_list 

dot  pred  <end_scopeXcheck_pred-ptype — typeX 

quant  <newjscope>  dec_list  ebar  pred  <unstaci<_pred-ptype> 

dot  pred  <end_scopeXcheck_pred-ptype — type>; 

quant  =  exi .  exil.  all; 

w  Predicates  n 

pred  = 

quant_exp» 

lo9_exp; 

a  Schema  terms  8 

schema_term  = 
quant  jsexp, 
lo9_sexp; 

quant_sexp  =  squant  <new_scope>  dec_list 

dot  schema_term  <subtract_scope-ptype — typeX 

squant  =  zexi,  zall; 

8  Logical  schema  expressions  8 

log  jsexp  = 
lo9_sexpl » 

log_sexp  z iff  lo9_sexpl  <stypeZ-ptype~ptype — typeX 

log_Sexpl  = 
logjsexpZ  f 

log_sexpl  z implies  log_sexp2  <stype2-ptype-ptype — type>; 

logjsexp2  = 
log_>exp3/ 

logjsexpZ  zor  log_sexp3  <stype2-ptype-ptype — typeX 

log  jsexp3  = 
l09_sexp4F 

log_sexp3  zand  log_sexpf  <stype2-ptype-ptype — typeX 

log_sexp^  = 
spec_sexpF 
znot  log_sexp4; 

8  Special-purpose  schema  expressions  m 
spec  jsexp  = 

spec_sexp  zhide  lpar  id_list  rpar  <hideids-pidl ist-ptype — type>, 
spec_sexp  zhide  reference  <hideref-ptype-ptype — type> , 
spec  jsexp  zemp  spec_sexpl  <scompose-ptype-ptype — typeX 
spec_sexp  zpipe  spec_sexpl  <pipe-ptype-ptype — typeX 
spec_sexp  zovr  specjsexpl  <soverr i de-ptype-ptype — typeX 
spec_sexpl ; 

specjsexpl  * 
spec_sexp2 > 

pre  spec_sexpZ  <pre-ptype — type>; 
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rename  = 

lsqb  rename_list  rsqb  < i d_i  nst-ptype-p i nst — type), 
decor  <decorate-ptype — type); 

spec_sexpZ  = 

lpar  schema_term  rpar. 

lpar  schema_term  rpar  rename/ 

ref erence  <check jschema-ptype — type) » 

schema ; 
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